I was comparing single pin simulation in Serpent 2.1.32 and OpenMC 0.14.0.dev0. Geometries are simple and the same (2D) and temperatures were checked to be the same, normalization is set to power=1000W, at the beginning only U235 and U238 are present heavy materials - HM.
1.) I discovered that fission reaction rate results for OpenMC are roughly 12.2% higher than those of Serpent. I believe that is due to the fact that OpenMC normalizes per prompt energy released. Reactor at steady state - eigenvalue - would it also incorporate this delayed energy release (fission products, neutron moderation, delayed beta, delayed gamma and capture-q))?
Following normalization of tally results described in the documentation:
fission_rate_normalized=fission_rate x power/(1.602e-19x heating),
by knowing the fission rate, power can be estimated by assuming all the fission occurs on U235 (fission rate x 202.27e6 eV x 1.602e-19 J/eV). This power is 1120 W using “heating” tally and 1020 using “heating-local” tally, which in any case is not the desired 1000W specified. I checked the U238 fission-q and it does not differ enough to cause the 20W discrepancy.
Does anyone know a fix?
2.) I ran depletion with butot in Serpent (array of sum of all previous time steps in OpenMC), timestep_units=“MWd/kgHM” in OpenMC in depletion, which in documentation says that is normalized per initial HM content (this correctly evaluates to the desired value). But results comparison shows that if the time is instead divided by the current HM content at each burnup step results match almost perfectly. HM content is about 10% lower at the the end of depletion compared to the initial HM content (i do not know which program is to blame Serpent or OpenMC).
Again the “scaling” of burnup could be due to the incorrect power that is decribed in 1.).
3.) In the documentation 10. Heating and Energy deposition it is described that the k_eff for eigenvalue calculation is corrected by photo-fission and fission products that cause fission. Is there a way to turn off this addition?
(Serpent runs only neutronics simulation)
Settings.photon_transport=False, still yields the same result.
Note: The difference of 80pcm may be from differently complied ENDF-7.1 database for the both programs.
After some discussion with my colleagues i got the following answers:
-
Yes fission-q is differently implemented in OpenMC and Serpent (more at: https://doi.org/10.1016/j.anucene.2020.107989).
This implementation in OpenMC yields higher results as described in the question above mostly likely due capture-q. Would it be possible to have an implementation that has these contributing to power as well?
-
It could be a bug that each step is calculated just-in-time and the operator calls itself for HM content at each step. Or it is just the power discrepancy.
-
By default only neutronics simulation is run, so i believe the difference should be in the cross-sections.
After a week of poking around i have successfully gotten agreeable results between OpenMC and Serpent:
-
Easiest way was to change fission energy release in Serpent: set U235H 193.4054000, for which i read the value from OpenMC depletion chain file. NOTE: Actual power output is higher as we are disregarding any delayed power from fission product decays and any power produced by absorption reactions other than fission.
For detectors i used Serpent predefined energy grid: ene egridd 4 scale238, for which the bins are defined in the Serpent manual. I converted them into an array multiplied by 1e6 (MeV to eV). In 2-D simulations Serpent gives some results normalised per unit length, so to get correct results you may need to multiply by 100. For OpenMC normalization use the tally “kappa-fission” and follow the guide. Watch out for volumes if any cell or material filters are applied.
-
For the solver I used the OpenMC default cram48 method, which is called in Serpent by: set bumode 2 -48 .
The problem was the integrator, only CE, CE/LI and LE/QI are supported by both programs. CE is quite unprecise and for the other two I am not sure in the same implementation. Nonetheless LE/QI integrator in OpenMC and for Serpent: set pcc 5 1 2 2 2 yielded results agreeing within 60 pcm at worst. NOTE: calculation time is quite a bit longer in OpenMC than in Serpent (maybe parallelization).
-
Make sure that the libraries used were compiled from the same ENDF file and if run on a cluster that slurm files have the correct PATH for the library.
Neutronics simulation is the default value in settings, photons are desregarded.
Note to any developers:
Can we get a local energy deposition addition for Q_capture like in Serpent: set edepmode 1 [some extra heating]?
@GasperSrsen The easiest way to achieve the local energy deposition accounting for capture is to modify a depletion chain file so that the Q values for fission include the energy from capture as well. You could do this through the Python API but manually editing the file is probably easier in this case.