CADIS WW geneartion from adjoint solution on exodus files

[not-fahim]

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]

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]

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]

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]

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]

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]

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]

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)