wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp by yrrepy · Pull Request #3942 · openmc-dev/openmc

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy · 2026-05-22T21:33:17Z

Description

This PR:

Fixes: openmc.WeightWindowsList.from_wwinp('wwinp') fails when processing wwinp files that are larger than ~2GB
Speeds-up WeightWindowsList processing (which gets to be slow with multi-GB wwinp).

WeightWindowsList.export_to_hdf5 raised MemoryError on multi-GB wwinp inputs because the XML path built multi-GB ASCII strings inside lxml. Now writes HDF5 directly via h5py, matching the C++ writer.
WeightWindowsList.from_wwinp was dominated by per-element isinstance checks in check_iterable_type (~90% of total time on multi-million- element bound arrays). Added a fast path for numpy float/complex ndarrays; ~11× speedup on a 172M-element wwinp (397 s → 35 s).

This enables support for many-GB wwinp files and faster processing of them.

An alternative re-factoring style is available here:
https://github.com/yrrepy/openmc/tree/wwinp_2GB_faster

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)

Float/complex ndarrays are dtype-validated, so the per-element isinstance() scan is redundant. Also construct upper_ww_bounds in WeightWindows.__init__ as an ndarray multiplication (not a list comprehension) so the upper-bounds setter benefits too. ~11x speedup on 172M-element wwinp inputs (397 s -> 35 s).

The XML serialization raised MemoryError on bound arrays >~200M elements -- lxml's intermediate ASCII allocation fails before the text node can be built. Write HDF5 directly via h5py, mirroring the C++ WeightWindows::to_hdf5 writer. Critical details for C++ compatibility: - Bounds are 2D (ne, n_voxels) on disk (4D would segfault the C++ tensor::Tensor<double> reader). - max_lower_bound_ratio is written unconditionally (default 1.0). - Root attrs filetype and version are required by openmc_weight_windows_import. Mesh writing is handled by a private _write_mesh_group helper in weight_windows.py that dispatches by mesh type, matching the reference implementation. UnstructuredMesh raises NotImplementedError (wwinp cannot produce one).

GuySten · 2026-05-28T17:26:15Z

- self.upper_ww_bounds = [
- lb * upper_bound_ratio for lb in self.lower_ww_bounds
- ]
+ self.upper_ww_bounds = self.lower_ww_bounds * upper_bound_ratio


The previous lines supported the case where self.lower_ww_bounds is a list.
The new lines do not support that.

Claude Code:
wrapped in np.asarray() so the line reads correctly even when
self.lower_ww_bounds is list-like. In practice the lower_ww_bounds setter
(L247-259) normalizes to ndarray via np.asarray, but the explicit wrap here
is clearer and costs nothing (no-op when already ndarray).
Perry:
OK, is defensive to have the explicit wrap

I've missed the fact that the setter guarantees that self.lower_ww_bounds is an array. So there is no problem.
I think your original code is better.

Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

GuySten · 2026-05-29T23:51:12Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

The dtype-trust fast path returned for any float/complex ndarray of matching depth, even when expected_type was int or another class -- the docstring promised element-type validation but the fast path skipped it. Gate the fast path on expected_type in (Real, float, complex) so it only fires when dtype.kind in 'fc' actually satisfies the contract.

The direct-h5py writer cannot serialize an UnstructuredMesh from pure Python: vertex and connectivity data live in the external .exo/.h5m file and only exist in memory after LibMesh/MOAB loads them via openmc.lib.init. Dispatch on mesh type up front: structured meshes take the new fast path; UnstructuredMesh falls back to the previous TemporarySession + openmc.lib.export_weight_windows route, which also restores honoring of init_kwargs on that path. Removes the dead NotImplementedError branch from _write_mesh_group.

yrrepy · 2026-05-30T00:53:12Z

Further checking the code, I had unwittingly disabled a Unstructured Mesh weight window workflow

d5251a8 tightens the check_iterable_type fast path so it only fires when expected_type is Real/float/complex (previously any float ndarray would silently pass even when an integer type was requested).
5f5ba87 restores the UnstructuredMesh path that the direct-h5py writer couldn't reach (pure Python can't materialize the external mesh data — falls back to the previous TemporarySession route, which also restores init_kwargs forwarding on that path)

Thoughts?

yrrepy · 2026-05-30T00:55:44Z

IMO the alternative refactoring style is better. It will be easier to support new mesh types when each mesh manage for itself the serialization to hdf5.

OK, I am agnostic, I just want my 2GB+ wwinps!

Do we need another opinion or should I just scrap this PR and start a new PR with the alternative approach?
Make sure it isn't disabling UM ww, etc.

GuySten · 2026-05-30T02:42:26Z

I think you can just open a new PR and close this one.
You can also ask for someone else opinion if you want.

yrrepy · 2026-05-30T15:10:50Z

Closed in favor of alternative approach #3951

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

yrrepy requested a review from pshriwise as a code owner May 22, 2026 21:33

yrrepy force-pushed the wwinp_2GB_faster_B branch from 09ed5dc to d3124eeCompare May 23, 2026 00:15

GuySten reviewed May 28, 2026
View reviewed changes

Address review: keep list compatibility in upper_ww_bounds derivation
a8d48d4
Wrap with np.asarray() so the derivation reads correctly even when self.lower_ww_bounds is list-like. No-op when already ndarray.

yrrepy added 2 commits May 29, 2026 17:35

yrrepy mentioned this pull request May 30, 2026
wwinp files: Fix MemoryError in WeightWindowsList.export_to_hdf5 and speed up from_wwinp. Alternative Approach #3951
Closed
5 tasks

yrrepy closed this May 30, 2026

paulromano mentioned this pull request Aug 7, 2026
Export large weight window files through openmc.lib without XML serialization #4057
Open
5 tasks

Uh oh!

Conversation

yrrepy commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

GuyStenMay 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

GuySten commented May 29, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

GuySten commented May 30, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

yrrepy commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

GuyStenMay 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

GuySten commented May 29, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

GuySten commented May 30, 2026

Uh oh!

yrrepy commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

yrrepy commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

GuyStenMay 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

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

yrrepy commented May 22, 2026•
edited
Loading

GuyStenMay 28, 2026•
edited
Loading

yrrepy commented May 22, 2026•
edited
Loading

GuyStenMay 28, 2026•
edited
Loading

yrrepy commented May 22, 2026•
edited
Loading

GuyStenMay 28, 2026•
edited
Loading

yrrepy commented May 22, 2026•
edited
Loading

GuyStenMay 28, 2026•
edited
Loading