-
Notifications
You must be signed in to change notification settings - Fork 503
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
Differentiate materials in DAGMC universes #3056
base: develop
Are you sure you want to change the base?
Conversation
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.
Not an easy task @bam241 and I think I see where you're going with it. My main concern with the current implementation is the amount of DAGMC-specific code in higher-level sections of the Python API. I think there's some refactoring we can do to avoid special logic in the Model
and (maybe) Geometry
classes.
I'd say this is optional for this PR, but now that we have additional DAGMC*
classes appearing I wonder if it would be best to move them all into a dagmc.py
file in the Python API. I thought doing this in the C++ code was nice as DAGMC constructs have their own special logic to some degree. It would reduce the size of our cell.py
and universe.py
files as well. I can tackle that afte we finish this PR though. Making an issue to track...
Co-authored-by: Patrick Shriwise <pshriwise@gmail.com>
@pshriwise I think I addressed your last round of comments. As I moved the DAGMCUniverse from I would suggest extra caution when reviewing those part, in case I missed any (I have been careful... but I might have missed something) and would ask for as much swiftness as we can have to conclude this (without impacting the quality) to avoid any additional complicated conflict :) |
@pshriwise here is an other illustration of the CI inconsistance: I have a PR with this branch on my fork, the |
openmc/lib/__init__.py
Outdated
@@ -68,6 +68,7 @@ def _uwuw_enabled(): | |||
from .math import * | |||
from .plot import * | |||
from .weight_windows import * | |||
from .dagmc import * |
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.
Let's either import the required function names directly or include an __all__
paramter in dagmc.py
to prevent symbol/name pollution from the wildcard import here.
@@ -211,15 +230,44 @@ void DAGUniverse::init_geometry() | |||
if (mat_str == "graveyard") { | |||
graveyard = vol_handle; | |||
} | |||
|
|||
// material void checks | |||
if (mat_str == "void" || mat_str == "vacuum" || mat_str == "graveyard") { | |||
c->material_.push_back(MATERIAL_VOID); | |||
} else { | |||
if (uses_uwuw()) { | |||
uwuw_assign_material(vol_handle, c); |
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.
How do we want the overrides to work when UWUW materials are present? I think that we'd want them to override UWUW material assignments as well.
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.
I did something about this:
- first check if override is path by cell ID,
- then check if uwuw is used to recover the material name (as override key),
- finally use the mat_str as override key
in all 3 cases, use to legacy assignment to override mat assignment.
tests/unit_tests/dagmc/test_model.py
Outdated
mats["Water"].add_s_alpha_beta("c_H_in_H2O") | ||
mats["Water"].name = "Water" | ||
|
||
p = pkg_resources.resource_filename(__name__, "dagmc_differentiate_mat.h5m") |
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.
In the interest of minimizing the number of binary files in the repo and it's overall size, would one of the other existing DAGMC files in the regression tests work for this test instead?
*n = dag_cell_ids.size(); | ||
} | ||
|
||
extern "C" int openmc_dagmc_universe_get_num_cells(int32_t univ_id, size_t* n) |
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.
We'll want all of these functions to return proper error codes to satisfy the C interface.
Another set of comments for you @bam241. Sorry if they're a little hard to track -- should've done a proper review. This is looking quite good! Just a few spots to polish up and I think it'll be ready |
Co-authored-by: Patrick Shriwise <pshriwise@gmail.com>
@pshriwise I added an other test, to check more extensively what is done, I can probably factorise some code between the 2 tests, will do today or tomorrow. Not that I had to remove the test that checked that the number of instance of the cells matched the number of instance of the override when applying the material assignment override in |
I also, make an addition split method, to allow splitting based on an arbitrary |
@pshriwise this is ready for a other round of review :) |
Description
This allows to differentiate materials in DAGMC universe when using the same DAGMC geometry to fill different CG cells
This provides a mechanism to overload material assignment embedded in the DAGMC geometry by providing a dict
{ref_mat_name:[mat_instances]}
This allows enrich the
Model.differentiate_depletable_material()
method from the Python API, to allows automatic differentiation of the depletable materials of a DAGMC geometry inserted multiple times.Checklist
this should address #2923
This work has been sponsored by NAAREA.