CADIS WW geneartion from adjoint solution on exodus files - #4063
Open
not-fahim wants to merge 4 commits into
Open
CADIS WW geneartion from adjoint solution on exodus files#4063not-fahim wants to merge 4 commits into
not-fahim wants to merge 4 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR adds the ability to build weight windows directly from multigroup adjoint flux stored as elemental data in an Exodus II file. This enables a CADIS or FW-CADIS weight window generation workflow in which the adjoint problem is solved by an external deterministic code that writes Exodus output (e.g. Griffin or other MOOSE-based solvers) and OpenMC consumes the result without any intermediate conversion step: the mesh in the file is registered as an unstructured (libMesh) mesh, the per-element flux is read for each energy group, FW-CADIS normalization is applied, and a WeightWindows object is created at simulation initialization.
Fixes #4061
Usage
In settings.xml:
or equivalently from the Python API:
python
One elemental variable is expected per energy group, ordered consistently with energy_bounds (ascending energy), so solvers that write group 0 as the fastest group need the variables listed thermal-first. Optional parameters omitted from the XML fall back to the existing WeightWindows defaults in the C++ layer.
Implementation notes
src/weight_windows.cpp / include/openmc/weight_windows.h: new non-member function read_weight_windows_exodus(pugi::xml_node) alongside the existing XML/HDF5 pathways, plus a small pure helper (fw_cadis_bounds).
src/mesh.cpp / include/openmc/mesh.h: a new owning constructor LibMesh(std::unique_ptrlibMesh::MeshBase, double, const std::string&), complementing the existing non-owning LibMesh(libMesh::MeshBase&). This exists because the flux read imposes constraints the filename constructor cannot satisfy, so the caller must build/read the mesh itself and then hand ownership to OpenMC.
src/settings.cpp: dispatch of the new element, placed before the existing "auto-enable weight windows if any are present" check so <weight_windows_on>false</weight_windows_on> retains its documented override behavior.
openmc/weight_windows.py / openmc/settings.py: new WeightWindowsExodus class (validation mirrors the C++ checks; XML round-trip supported) and a Settings.weight_windows_exodus attribute.
Checklist