Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix find_all_active_cells_around_point() #14728

Merged

Conversation

peterrum
Copy link
Member

@mschreter Could you take over and add a test. Thx!

@peterrum peterrum added the Bug label Jan 25, 2023
@tamiko tamiko changed the title [WIP] Fix find_all_active_cells_around_point() Fix find_all_active_cells_around_point() Jan 26, 2023
@mschreter
Copy link
Contributor

mschreter commented Feb 7, 2023

This PR extends find_all_active_cells_around_point() to return the right number of cells for a point located on the cell edge/corner between elements of different refinement levels, e.g. as the pink marked point in the figure below.

image

Previously if the pink point was requested within RemotePointEvaluation, the following assert would have been triggered:

--------------------------------------------------------
An error occurred in line <352> of file </home/much/work/libs/dealii/include/deal.II/grid/tria_iterator.templates.h> in function
    dealii::TriaActiveIterator<Accessor>::TriaActiveIterator(const dealii::TriaIterator<Accessor>&) [with Accessor = dealii::CellAccessor<1, 1>]
The violated condition was: 
    this->accessor.has_children() == false
Additional information: 
    (none)

@nmuch FYI

@mschreter mschreter force-pushed the find_all_active_cells_around_point branch from 2cf85c6 to 3102dd8 Compare February 7, 2023 10:23
@mschreter
Copy link
Contributor

Ready to review from my side!

@peterrum
Copy link
Member Author

peterrum commented Feb 7, 2023

/rebuild

@peterrum
Copy link
Member Author

peterrum commented Feb 7, 2023

@mschreter Could you add a change-log entry?

Co-authored-by: Magdalena Schreter <schreter.magdalena@gmail.com>
@mschreter mschreter force-pushed the find_all_active_cells_around_point branch from 3102dd8 to ca161a5 Compare February 7, 2023 11:34
Copy link
Member Author

@peterrum peterrum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mschreter Thanks 👍

@masterleinad masterleinad merged commit 4efb66e into dealii:master Feb 7, 2023
@peterrum
Copy link
Member Author

peterrum commented Feb 7, 2023

@mschreter When looking at the picture in #14728 (comment), I think you are testing at the wrong place. It should be at (0.5, 0.25). Also would it be possible to switch the order of refinement. You have refined left. I would like to see also on the right. The motivation is that it makes the difference from which side the algorithm is run.

@mschreter
Copy link
Contributor

@mschreter When looking at the picture in #14728 (comment), I think you are testing at the wrong place. It should be at (0.5, 0.25). Also would it be possible to switch the order of refinement. You have refined left. I would like to see also on the right. The motivation is that it makes the difference from which side the algorithm is run.

I've tested (0.25,0.25), which is not a hanging node but is connected to cells at different levels. I thought this should be a critical point as well (not only hanging nodes). Nevertheless, I could extend the test case in a follow-up PR regarding (i) including a hanging node request and (ii) switching refinement direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants