Export large weight window files through openmc.lib without XML serialization by paulromano · Pull Request #4057 · openmc-dev/openmc

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano · 2026-08-07T19:54:22Z

Description

Background

WeightWindowsList.export_to_hdf5() currently creates a temporary model containing the weight windows, writes that model to XML, initializes the OpenMC shared library from the XML, and then calls the existing C++ HDF5 exporter. For weight window files containing hundreds of millions of values, constructing the ASCII representation of the bounds can require multiple GBs of additional memory and eventually raise MemoryError.

#3942 addressed this by implementing a direct HDF5 writer in Python with h5py. #3951 refined that design by moving mesh serialization into methods on each mesh subclass. Both approaches avoid the large XML document, but they introduce a second implementation of the weight window HDF5 format alongside the existing C++ writer. This duplicates format logic across Python and C++, requires the Python implementation to remain synchronized with future format changes, and makes the C API responsible for passing HDF5-specific hid_t values across the language boundary. PR #3951 also introduces a separate cleanup operation to manage objects created for this export path.

Approach

This PR avoids XML serialization while continuing to use the existing C++ HDF5 writer. WeightWindowsList.export_to_hdf5() initializes a minimal temporary OpenMC library session and creates the required meshes and weight windows directly through openmc.lib. Once the C++ objects have been populated, it calls the existing openmc.lib.export_weight_windows() function. The weight window bounds therefore never need to be represented in XML.

A new public MeshBase.to_lib_object() method creates the corresponding runtime mesh in an initialized OpenMC library session. It supports regular, rectilinear, cylindrical, spherical, and unstructured meshes. The necessary mesh names, origins, unstructured-mesh options, length multipliers, and IDs are transferred through APIs using ordinary C-compatible data types. The existing openmc_add_unstructured_mesh() API is extended to accept all properties needed to reproduce a Python unstructured mesh directly in the library.

This design retains the primary benefit of PRs #3942 and #3951: multi-GB weight window data no longer passes through XML. Unlike those approaches, it preserves a single implementation of the weight window HDF5 format. Changes to the format only need to be made in the existing C++ writer, and Python does not need to reproduce C++ serialization behavior with h5py.

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)

GuySten · 2026-08-10T08:11:55Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


IMO, each mesh subclass should implement how to convert itself to its lib counterpart.
That way we don't have to edit this function when implementing a new mesh type.

I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

Agreed. I moved the conversion to openmc.lib as openmc.lib.Mesh.from_python(mesh). Each concrete openmc.lib mesh subclass now implements its own _from_python() conversion hook, while the base method only selects the matching subclass and handles shared behavior such as the initialization check, ID, name, and base directory.

pshriwise

Looks nice @paulromano! Good idea to address the duplicate implementation issue. There's more than enough to keep track of as it is.

Some design conversation to he bad about which side (Python API or openmc.lib) should initiate the object transfers.

pshriwise · 2026-08-10T17:49:40Z

+ lib_meshes[mesh.id] = mesh.to_lib_object(
+ base_dir=original_dir)
+
+ lib_ww = openmc.lib.WeightWindows(ww.id)


Perhaps the openmc.lib.WeightWindows class could have a classmethod that takes in an openmc.WeightWindows object to handle some of the setup going on here.

Good suggestion! I've added openmc.lib.WeightWindows.from_python(), which limits the logic here to managing the temporary session, deduplicating shared meshes, invoking the conversion, and calling the existing C++ exporter.

pshriwise · 2026-08-10T17:54:18Z

 int openmc_mesh_filter_set_translation(int32_t index, double translation[3]);
 int openmc_mesh_get_id(int32_t index, int32_t* id);
 int openmc_mesh_set_id(int32_t index, int32_t id);
+int openmc_mesh_get_name(int32_t index, const char** name);


Let's add some tests for these new functions in test_lib.py

Implemented new tests that cover these

pshriwise · 2026-08-10T18:00:44Z

+ uid = self.id
+ base_dir = Path.cwd() if base_dir is None else Path(base_dir)
+
+ if isinstance(self, RegularMesh):


I tend to agree.
In the vein of my other comment, this also feels appropriate for a classmethod approach on the openmc.lib.Mesh object where each subclass handles its own property settings for the resulting openmc.lib object.
e.g.
lib_mesh=openmc.lib.Mesh.from_python_object(spherical_mesh).
This makes it more natural (to me) to ensure that the openmc.lib module is initialized before performing these operations.

paulromano · 2026-08-27T18:51:17Z

Thanks @GuySten and @pshriwise for the review! All your comments have been addressed.

pshriwise

Once last small comment from me, but otherwise I think this looks great!

pshriwise · 2026-08-31T20:15:20Z

+ ----------
+ mesh : openmc.MeshBase
+ Python API mesh to convert.
+ uid : int, optional


Is this parameter used anywhere in the code currently?

GuySten · 2026-08-31T20:18:18Z

I suggest waiting for #4091. Which touches the same code.

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

paulromano added 5 commits August 3, 2026 14:08

Initial implementation of C++ based WWList export
92ce1e7

Expose MeshBase.to_lib_object
4aeabad

Simplify Model use
9708ec0

Use existing openmc_add_unstructured_mesh function
ed9b48c

Move/add tests
b4633d0

paulromano requested a review from pshriwise as a code owner August 7, 2026 19:54

GuySten reviewed Aug 10, 2026
View reviewed changes

pshriwise requested changes Aug 10, 2026
View reviewed changes

Use lib.Mesh.from_python instead of Mesh.to_lib_object
6386b30

paulromano added 2 commits August 27, 2026 14:16

Merge branch 'develop' into wwinp-direct-lib-export
fbfdc8a

Use feature_enabled
fa325e3

GuySten mentioned this pull request Aug 31, 2026
Fix weight window energy defaults being derived before the particle type is known #4091
Open
5 tasks

pshriwise reviewed Aug 31, 2026
View reviewed changes

Uh oh!

Conversation

paulromano commented Aug 7, 2026

Description

Background

Approach

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulromano commented Aug 27, 2026

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuySten commented Aug 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

paulromano commented Aug 7, 2026

Description

Background

Approach

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulromano commented Aug 27, 2026

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!