Duplicate mesh writing in XML files.

[pshriwise]

Currently, if a user wants to use the same mesh for two different purposes, the mesh might be written to multiple XML files. When reading the XMl files, OpenMC will find two meshes with the same ID, report an error, and exit.

For instance, a user may want to apply the same mesh for a mesh tally and the Shannon entropy mesh. Both the openmc.Settings object and openmc.Tallies object will write that mesh to the settings.xml and tallies.xml files, respectively.

[eepeterson]

Would this potentially be a reason to move to a single model.xml input file that has elements comprised of the existing necessary XML input files? To me this seems a bit more portable and easier for QA whereas reference IDs for various tallies, materials, geometry, etc can easily get mixed up if you try to copy a set of XML inputs and do quick edits to run a new case. Within this context it should be pretty easy to avoid duplicate writing of identical meshes or other things.

[paulromano]

@eepeterson Yes, that is one possibility for dealing with this. Some other possible approaches:

• Have a separate meshes.xml file that the other files reference
• Only write a mesh the "first time" (with #1990 this will technically work)

The last option is certainly the simplest, but the least robust. For the reasons you outlined and others, we may want to have the option of having a single model.xml file in the future.

[eepeterson]

@paulromano I think PR#1990 is a good work around if we want to address this immediately. In the single model.xml file paradigm, I would be supportive of another subsection for meshes explicitly so that tallies and settings can reference meshes by id more clearly. If this is a bit longer term, I think the separate meshes.xml file in the interim makes sense since then the model.xml file could simply be a collation of all the necessary input xml files.

[pshriwise]

Reviving this conversation in regards to the model.xml file. There seem to be an increasing number of places where exporting via the model class to a single XML has advantages. #2264 related to this too in the sense that having all of this information in a single file would allow us to resolve those inconsistencies.