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

Differentiate materials in DAGMC universes #3056

Open
wants to merge 80 commits into
base: develop
Choose a base branch
from

Conversation

bam241
Copy link
Contributor

@bam241 bam241 commented Jun 22, 2024

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

  • I have performed a self-review of my own code
  • I have run clang-format (version 15) on any C++ source files (if applicable)
  • I have followed the style guidelines for Python source files (if applicable)
  • I have made corresponding changes to the documentation (if applicable)
  • I have added tests that prove my fix is effective or that my feature works (if applicable)

this should address #2923

This work has been sponsored by NAAREA.

@bam241 bam241 marked this pull request as ready for review August 12, 2024 15:30
Copy link
Contributor

@pshriwise pshriwise left a 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...

openmc/lib/dagmc.py Outdated Show resolved Hide resolved
openmc/lib/dagmc.py Outdated Show resolved Hide resolved
openmc/model/model.py Outdated Show resolved Hide resolved
openmc/model/model.py Outdated Show resolved Hide resolved
openmc/model/model.py Outdated Show resolved Hide resolved
openmc/universe.py Outdated Show resolved Hide resolved
openmc/universe.py Outdated Show resolved Hide resolved
openmc/universe.py Outdated Show resolved Hide resolved
include/openmc/cell.h Show resolved Hide resolved
openmc/geometry.py Outdated Show resolved Hide resolved
@bam241
Copy link
Contributor Author

bam241 commented Oct 11, 2024

@pshriwise I think I addressed your last round of comments.

As I moved the DAGMCUniverse from openmc.universe to openmc.dagmc and shuffled some methods from Universe to UniverseBase ,
in the mean time openmc.universe has been updated on develop,
It is difficult to make sure I didn't miss any update to DAGMCUniverse, Universe and UniverseBase while resolving the conflict.

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 :)

@bam241
Copy link
Contributor Author

bam241 commented Oct 12, 2024

@pshriwise here is an other illustration of the CI inconsistance:
bam241#1

I have a PR with this branch on my fork, the [Python 3.10 (omp=y, mpi=y, dagmc=y, ncrystal=, libmesh=, event= vectfit=)](https://github.com/openmc-dev/openmc/pull/3056#logs) test failed after 6h. while here it worked in 1h

include/openmc/dagmc.h Outdated Show resolved Hide resolved
@@ -68,6 +68,7 @@ def _uwuw_enabled():
from .math import *
from .plot import *
from .weight_windows import *
from .dagmc import *
Copy link
Contributor

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.

openmc/model/model.py Outdated Show resolved Hide resolved
openmc/model/model.py Outdated Show resolved Hide resolved
@@ -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);
Copy link
Contributor

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.

Copy link
Contributor Author

@bam241 bam241 Oct 30, 2024

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.

mats["Water"].add_s_alpha_beta("c_H_in_H2O")
mats["Water"].name = "Water"

p = pkg_resources.resource_filename(__name__, "dagmc_differentiate_mat.h5m")
Copy link
Contributor

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)
Copy link
Contributor

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.

@pshriwise
Copy link
Contributor

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

@bam241
Copy link
Contributor Author

bam241 commented Oct 31, 2024

@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 dagmc.cpp.
The number of instances of the Cell is determine after loading the DAGMC model, therefore it is 0 when loading the DAGMC geometry... so we can't test against it at this moment...

@bam241
Copy link
Contributor Author

bam241 commented Oct 31, 2024

I also, make an addition split method, to allow splitting based on an arbitrary delim, some material names (i.e. in the actual dagmc.h5 used in the test) have space in it, therefore space is not a proper delimiter to separate the list of material names use for the override.
I used ; instead

@bam241
Copy link
Contributor Author

bam241 commented Nov 13, 2024

@pshriwise this is ready for a other round of review :)

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

Successfully merging this pull request may close these issues.

3 participants