XML Writer and Geometry Initialization Counter Caching
Created by: pshriwise
This draft is for discussion of a solution I implemented to improve performance for model generation and simulation initialization of the Holos-Quad reactor model designed by HolosGen LLC. The design employs a graphite moderator with embedded TRISO particles, about ~500k per fuel region w/ 19 regions per assembly, ~50 assemblys per module, and 4 modules. Due to the sheer number of cells and universes in the geometry, the model was taking a very long time to generate via the Python interface as well as initialize for simulation.
I'm not yet seeking line comments or minor design comments on the changes, just looking to share the idea and start a conversation. I'm not as familiar with the breadth of use OpenMC sees and there may be obvious use cases where these ideas wouldn't play out well.
If there aren't any serious objections to the concepts below, I'll move forward with cleaning up the implementation and design and submit it as a proper PR.
Model generation was taking more than 10 hours, largely due to a check for previously written surfaces, cells, lattices, and universes in the
create_xml_subelement method of many geometric classes. This check was using xml's
element.find() method, which was the source of the long model generation time.
I say current solution because it's subject to change.
I've implemented a singleton class which creates sets of IDs for cells, surfaces, etc. The check for containment in a set is more efficient, reducing the model generation time to ~20 min.
Because this class is a singleton, I'm a little worried about the right time to reset this data structure and how to trigger that reset in all the ways users might find themselves using the Python interface.
Same as the model generation section. It was taking an inordinate amount of time to start a simulation.
Also used a dynamic programming solution here. This time, I needed singleton classes which would let me properly increment counters for the number of cells in universes and the number of levels underneath a universe as well as update counters using cell/level counts from other universes. This addition took the simulation setup form an indeterminate amount of time (+12 hours) to 3-4 min.
Of the two parts to this work, I'm more comfortable with the Cell/Level counters as it seems more clear to me when these data structures should be reset and are less exposed to unexpected used compared to the
ElementTracker class in the Python interface.