-
Notifications
You must be signed in to change notification settings - Fork 46
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
Enable Adaptive Mesh Refinement #964
base: devel
Are you sure you want to change the base?
Conversation
- Added an active element check to ensure that we only map to elements which store variables.
- Added a workaround to the equation system in `openmc::LibMesh` meshes throwing an error when meshes are programmatically refined. - Added a way to programmatically determined if adaptivity is enabled in OpenMCCellAverageProblems.
Job Documentation, step Sync to remote on b598421 wanted to post the following: View the site here This comment will be updated on new commits. |
For some reason the AMR MeshTally test crashes in CIVET, but doesn't crash on Pinchot or my local machine. I've ran the test through gdb and Valgrind (thorough memtest) and it executes successfully, so I'm at a bit of a loss at the moment.
This wasn't the cause. Valgrind and GDB both report no errors when testing this branch compiled without the MOOSE Conda environment. |
5c58365
to
0566576
Compare
Job Precheck, step Clang format on 80b23d2 wanted to post the following: Your code requires style changes. A patch was auto generated and copied here
Alternatively, with your repository up to date and in the top level of your repository:
|
9441a89
to
3bbcd61
Compare
@aprilnovak I managed to track down and patch the bug that's been plaguing this PR; it should be good for review now. |
src/base/OpenMCCellAverageProblem.C
Outdated
setupProblem(); | ||
} | ||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain where this went?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This #else
statement was the cause of the segmentation faults on CIVET, and more generally it resulted in memory leaks when Cardinal is built without DAGMC and using a moving mesh.
When the mesh is changing OpenMCCellAverageProblem needs to reset tallies on every timestep (after the first step), and so it calls resetTallies()
at the beginning of the step. This is immediately followed by a call to setupProblem()
. Afterwards, if the mesh is moving setupProblem()
is called a second time in that #else
statement resulting in an initialization of OpenMC tallies twice for each time they're reset. This causes a memory leak as we don't manage the extra OpenMC tally created on each step.
The reason why this caused a segmentation fault is a little more complicated and involves the copy of the mesh created in MeshTally
containing only active elements. This mesh copy is deleted both when resetTally()
and initializeTally()
are called (it's a unique pointer). Since we've been creating two OpenMC tallies per timestep (by accident) the first of those tallies still thinks the mesh copy is valid, and so it tries to tally on datastructures that have had their memory freed. This behaviour is undefined and results in a segmentation fault.
This bug only occurs when Cardinal is compiled without DAGMC as resetTallies()
is called again when skinning the geometry (the previous usecase for the #ifdef
/#else
statement), so nothing breaks.
type = CSVDiff | ||
input = cell.i | ||
csvdiff = cell_out.csv | ||
requirement = "The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this test show exactly? Can we see the outlines of a CSG cell become more refined as the mesh changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test ensures that problems can run mesh adaptivity when using cell tallies, so it's measuring the increasing number of elements. It's really just a surrogate for a RunApp
executioner with some extra information attached.
Would you please also add a news markdown file to announce this capability? I think it warrants it! |
@aprilnovak I can definitely do that! Should I also add an entry for the filter system (since it's a pretty big addition to Cardinal as well)? |
This PR enables adaptive mesh refinement for the OpenMC mesh mirror. This allows for the use of AMR (as implemented in MOOSE) within Cardinal.
The main changes include looping over active elements instead of all elements when generating the cell -> element map and creating a copy of the mesh containing only active elements when using a
MeshTally
. The latter is required for two reasons: to avoid errors which are thrown by MOOSE because of the equation system created in theopenmc::LibMesh
class, and to prevent erroneous tallying on non-active elements in the refinement/coarsening hierarchy. Creating a copy of the mesh without the refinement hierarchy is a severe limitation of the current approach and should be remedied in the future.