get_microxs_and_flux Incorrect Meshbase

[yrrepy]

Bug Description

get_microxs_and_flux uses the meshbase of an existing weight window rather than prescribed domains meshbase

Steps to Reproduce

• take an OpenMC model
• apply weight windows
• use openmc.deplete.get_microxs_and_flux(domains=openmc.MeshBase)
• no new meshbase is created (corresponding to the domains), rather the existing weight window mesh is erroneously used by the get_microxs_and_flux calculation

Environment

Linux OpenMC 0.15.3.dev99

Workarounds

• can adjust the ww.h5 manually to change the ww and mesh ids to something other than 1
• can adjust the model.xml manually to ids other than

thing is the natural workflows will tend to auto-assign it in Python to id=1

[paulromano]

I'm a little confused. The domains argument to get_microxs_and_flux should be a specific instance of MeshBase, not the MeshBase class itself.

[yrrepy]

perhaps the wrong words. I am creating a regular mesh openmc.RegularMesh(), using it as the domains. get_microxs_and_flux is ignoring it and using the existing mesh of the weight window

[pshriwise]

To make sure I'm understanding, @yrrepy, it sounds like this occurs when the Mesh IDs are the same? Is that correct?

If so, follow up: in this scenario are you applying weight windows as XML objects or using a weight windows HDF5 file?

[yrrepy]

I'll look to draw up an example when I can, it's hard as there are many moving parts with prop data This was using wws=from_xml (so as XML)

At large, I'm having all number of knock-on situations:

• the wws from_wwinp often fails when wwinps are >1.5 GB (it fails at the XML writing stage)
• which motivates ww.h5, but then the API doesn't currently support ww.h5 (model imports).
• Then you don't auto-get your mesh and have to hard program it in.