Skip to content

CADIS WW geneartion from adjoint solution on exodus files - #4063

Open
not-fahim wants to merge 4 commits into
openmc-dev:developfrom
not-fahim:CADIS-w-Griffin-PR
Open

CADIS WW geneartion from adjoint solution on exodus files#4063
not-fahim wants to merge 4 commits into
openmc-dev:developfrom
not-fahim:CADIS-w-Griffin-PR

Conversation

@not-fahim

Copy link
Copy Markdown

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:

xml
<weight_windows_exodus>
  <file>adjoint.e</file>
  <adjoint_flux_variables>flux_g1 flux_g2</adjoint_flux_variables>
  <energy_bounds>0.0 1.0e5 2.0e7</energy_bounds>
  <!-- optional: <timestep> (default: last step), <particle_type> (neutron),
       <survival_ratio> (3.0), <upper_bound_ratio> (5.0), <max_split> (10) -->
</weight_windows_exodus>

or equivalently from the Python API:

python

import openmc

settings = openmc.Settings()
settings.weight_windows_exodus = openmc.WeightWindowsExodus(
    file='adjoint.e',
    adjoint_flux_variables=['flux_g1', 'flux_g2'],
    energy_bounds=[0.0, 1.0e5, 2.0e7],   # or an openmc.mgxs.EnergyGroups
)

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

  • I have performed a self-review of my own code
  • I have run clang-format (version 18) 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)

@not-fahim
not-fahim requested a review from pshriwise as a code owner August 14, 2026 15:11
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.

CADIS or FW-CADIS Weight windows from adjoint solution on exodus files

1 participant