I’ve got a problem in a GODIVA benchmark like calculation. In eigenvalue calculation, the results of kappa-fission, flux and fission rate match well with mcnpx. But when I place a 14MeV fixed source in the center of the sphere and do the fixed source calculation, the results given by mcnpx are hundreds of times of OpenMC. It seems that the results given by mcnpx is more reasonable, is OpenMC wrong? This confused me a lot, could you help me? The model and results are given below.
The problem is that the model itself is very close to critical (keff=0.99551 as you saw). When run in fixed source mode, it becomes a subcritical multiplication problem. However, at the moment, OpenMC can only handle subcritical multiplication problems up to about keff=0.99. Beyond that, too many fission neutrons are created and will eventually exceed the size of the secondary particle bank. When I try to run your problem with a 14 MeV point source in the center of the sphere, I eventually get the following error:
ERROR: Secondary particle bank size limit reached. If you are running a
subcritical multiplication problem, k-effective may be too close to one.
Perhaps MCNPX has a method for handling subcritical multiplication problems that are close to critical. If you are interested in such a functionality for OpenMC, I’d encourage you to create an issue on our github repo.
Thank you for your response. I’ve made a mistake before. In the openmc fixed source calculation, the composition of 235U was wrongly written as 0.04, so the keff of the system is 0.904. After correcting this mistake, openmc gives a kappa-fission of 131.294MeV, the error you mentioned didn’t appear. My openmc version is 0.7.1.
I change the keff to 0.9 and 0.48 by reducing the composition of 235U to 0.04 and 0.02. But the kappa-fission value doesn’t match with the result given by MCNPX. What could be wrong?
There was no support for subcritical multiplication in version 0.7.1, so in a fixed source calculation, fission would be treated as absorption with no neutrons created. Support for subcritical multiplication was added in version 0.8, so to get comparable answers with MCNPX, you will need to upgrade to version 0.8.
Hi Paul,
Thank you for your help. I’ve upgraded my OpenMC to version 0.8, and the results match well with MCNPX. Then,I tried to perform an fixed source problem using an OECD ADS benchmark model, the spallation neutrons were given by FLUKA, and I transferred to hdf5 format source file . When I ran OpenMC, it reported:
Loading ACE cross section table: 25055.03c
Maximum neutron transport energy: 20.0000 MeV for 94238.03c
Initializing source particles…
Reading source file from /home/shong/openmcwork/source.h5…
Can you try compiling with debug flags turned on (cmake -Ddebug=on …) and re-running? This should give you a traceback when it segfaults so we can at least determine where the problem is stemming from.
pure function constant1d_evaluate(this, x) result(y) 1
Warning: Unused dummy argument ‘x’ at (1) [-Wunused-dummy-argument]
I don’t know whether it matters and I attached these to the zip file.
After compiling and running OpenMC, it reported:
Simulating batch 1…
At line 222 of file /home/shong/openmc-0.8.0/src/cross_section.F90
Fortran runtime error: Index ‘8001’ of dimension 1 of array ‘nuc%grid_index’ above upper bound of 8000
So I changed the neutron energy of 20MeV to 10MeV in the source.h5 file, OpenMC could run but with these warnings:
Particle XXXX underwent maximum number of events
and finally got this fault:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f5cbcd6edf7 in ???
#1 0x7f5cbcd6e02d in ???
#2 0x7f5cbbe1b7df in ???
#3 0x0 in ???
Segmentation fault (core dumped)
I don’t known how to solve this, so I put all the input files and source.h5 file in the attachment. Hope you can help me.
I don’t know if you ever figured out what was going on with your model. I took a look at it and noticed a few issues:
Cells 2 and 3 are overlapping
The tag is misspelled for Np-237 in material 2
The tag is misspelled for Mo in material 3.
That being said, even with those fixed I still get the error you are seeing. It looks like there may potentially be a bug in the treatment of complex cells. One way you can get around it in the meantime is to split your definition of cell 4 into three separate cells, each of which is defined only with intersections.
Another issue that I will look into getting fixed is that right now fixed source simulations do not work with a source file. Do you absolutely need to run in fixed source mode or can you use an eigenvalue calculation for what you’re doing?
Thank you for your response. I’m a postgraduate student in University of Science and Technology of China and I’m trying to apply OpenMC in our CIADS(China Initiative Accelerator Driven System) project by coupling with FLUKA. So it is necessary to run in fixed source mode. I’ve noted the problem I found in the simulation.f90 in another post. I’ll fix these mistake and try again.
I notice that in the “Changes since version 0.8.0”, you say “OpenMC now uses an HDF5 format for cross sections rather than ACE libraries” but I’m still using ace libraries and it doesn’t report any error. Besides, you say "All energies are now in eV rather than MeV“, it seems that the energies in source file and source definition are still in MeV, is this just apply to the input xml files?
If you are using ACE libraries and your version of OpenMC is still working, then it must be a version from July 2016 or earlier. The switch to HDF5 data libraries was made in late July last year. The change of energy units affects everything – cross section data, source files, input files, output files, etc.