I am running an OpenMC eigenvalue simulation on 12 OpenMP threads on a single machine to compare calculated Keff against what I get from Serpent on an MSBR model with the same settings. The Keff values themselves match up well (OpenMC gives 1.09890 +/- 0.00123, Serpent gives 1.09760 +/- 0.00099) , but the difference in solve time is quite significant. Serpent only takes about one or two minutes to perform the solve, whereas OpenMC takes up to 15 minutes with the same settings! The geometry is quite complicated, but that doesn’t explain why Serpent is able to solve so much faster than OpenMC. Any idea as to what could be going on?
I’ve found some info from @smharper in a GH Issue about Delta tracking from 2018:
Also I should mention that if you’re looking for a speedup in terms of tracking, it’s worth trying to define your geometry in a couple of different ways. Complex cells (cells that use the ~ or | operators in their region specification) can significantly slow a calculation down. OpenMC will also slow down a lot if you have one surface that is used by many cells. This can happen, for example, if you cut a fuel pin into 100 axial cells and each uses the same ZCylinder for the outer radius; and you’ll see a big speedup if you instead use lattices to do the axial cuts.
I do have some areas where I use the ~ and | operators in my geometry. I will try to remove these to speed up the calculation.
I’ve attached the relevant input files below.
System information:
OS: Ubuntu 22.04
OpenMC: 0.14.0-dev
Serpent: 2.1.32
OpenMC files:
geometry.xml (123.0 KB)
materials.xml (1.5 KB)
settings.xml (385 Bytes)
Serpent files (uploaded as python files bc that’s what is allowed)
msbr_endfb71.serpent (2.5 KB)
msbr_saltproc_prepr_comp_endfb71.ini (325 Bytes)
msbr_full_optimized.ini (49.5 KB)
Update: I’m chipping away at removing complex regions, which is increasing the cell count of my model by quite a bit. At some point, will the number of cells start to become a constraint? That is, is there some optimal CSG representation of the geometry that balances region complexity against the number of cells? @paulromano @pshriwise
Hi @oyardas2,
First off, very cool model! I pulled it up in the plotter to have a look 
Regarding your question about number of cells vs. complexity, there isn’t a clear answer for this, unfortunately. There are a lot of parameters to, as you aptly put it, balance here: number of cells, number of cells per surface, surface types, region complexity, etc. The best thing to do is to profile the run to see where you’re spending time.
I did do some profiling on the original model you provided and it seems to spend quite a bit of time in the ZCylinder::distance method. There are a lot of those in the model, so this isn’t too surprising.
That aside, I went ahead and ran this on my machine (AMD Ryzen 9 5950X) with 12 threads and it only took a minute or so to run, so maybe something else could be causing the low particle rates? (i.e. build config and such)
Maybe with your updates for simple cell definitions you’re running faster now though, idk.
Hope this helps!
-Patrick
Hi Patrick,
Thanks for taking a look at this! I hadn’t thought of using a profiler (to be honest I don’t I’ve ever actually used one). I believe I need to build OpenMC with that capability though.
In hindsight, I believe I have OpenMC installed in Debug mode, which may be a cause for the slowdown.
Reinstalling OpenMC in Release mode fixed the slow simulation!
1 Like
Hi oyardas2,
May I ask how you developed such a geometry.xml file? What software did you use and if possible how did you import it , i.e dagmcUniverise?
I am struggling to create a custom geometry my forum post : DAGMC Geometry Assitance
Hi @AnthonyB08,
I based my geometry on a model created by Andrei Rykhlevskii for his theses (MS, PhD), which itself is based off of the original specifications of the MSBR. These models were made purely in CSG! 
The script I wrote to generate the geometry is openmc_msbr_model.py, located in this subdirectory of the SaltProc repository, and the description of the model and all of it’s assumptions can be found in Chapter 4 of main.pdf linked to in this issue.
Hope this helps!
Olek
