Hi all,
I’m having an issue when running a fixed source problem in multigroup mode, in particular when specifying the energy distribution to use with the source. I would expect that using an stats.Discrete distribution with a single energy point for the source would create a source in the group that includes that energy, but I haven’t found that to be the case. Instead, OpenMC seems to always select the first energy group except when the discrete energy specified is above any of the energy groups. Looking at the code for the source in lines 130-140, it looks like specifying a discrete energy for the source should select the correct energy group if the binary search works correctly.
I’ve attached a minimal example that tests several discrete values of energy for the source (line 92) and then prints out the expected group based on the energy bounds and the group returned for a sample source particle. For the energy bounds of [7, 8, 9, 10], I test energy values of [6.5, 7.5, 8.5, 9.5, 10.5]. I would expect based on the code for the source that OpenMC would return the energy groups [1, 1, 2, 3, 3] for the source particles based on these discrete values, but instead it returns [1, 1, 1, 1, 3]. This pattern persists for other, more realistic values of energy. Is there an error in my source specification that might explain what’s happening?
Thanks,
Brody
run.py (4.09 KB)
Hi again,
After some debugging, it looks like the issue is the order of the energy groups in OpenMC. The Python script requires that the group edges are ordered from smallest to largest. The algorithm to find the appropriate group in lines 130-140 of source.F90 also assumes that the group edges are ordered from smallest to largest. However, in lines 4215-4216 of input_xml.F90 the order of the energy groups is reversed. It could be that this new array of reversed energy groups is meant to be assigned to the “rev_energy_bins” array that is allocated just before. When I change the two lines below, the code works as expected in the cases I’ve tested.
input.F90 at line 4216: rev_energy_bins = energy_bins(num_energy_groups + 1:1:-1)
tally_filter_energy.F90 at line 78: if (all(this % bins == energy_bins)) &
Brody
Brody,
Nice detective work you’ve done. I believe the energy_bins array is supposed to have the energies reversed, so the error would really be in source.F90 where it assigns a group based on an ascending list of energies. I’ve CCed Adam Nelson who developed the MG mode for OpenMC to confirm that the error is indeed in source.F90 and not elsewhere.
Any interest in making a pull request to fix this once we settle on the right file, Brody?
Best regards,
Paul
Morning Brody,
Great find. I suspect I decided I didn’t need rev_energy_bins, but 1) I did it poorly since I never deleted the unused array, and 2) I was wrong since source.F90 was clearly written assuming the energy_bins array was not reversed.
Your proposed changes seem to work for that problem, in fact it should improve tallying efficiency since the energy bin check doesn’t need to reverse the order of the array.
If you’re interested in doing this PR, I’d also recommending checking cmfd_input.F90 for consistency. Looks like your changes should work fine there, but keep an eye out. If not, let us know.
Thanks,
Adam
p.s. Great to see some adoption of OMC at UM!
Paul and Adam,
I would be happy to make a pull request once I verify none of the tests are broken with the changes.
I appreciate that you guys support running in multigroup in OpenMC. It works great for generating multigroup cross sections and benchmark solutions for deterministic problems.
For fixed-source problems, I would have expected that the estimators in the problem would be multiplied by the sum of the strengths from all the “source” instances. Instead, the strength seems to only be used for the relative weight of the individual sources. To calculate the scalar flux from the estimators, I multiply the result of the estimator by the expected integral strength of the source and then divide by the estimator volume. Is there a better way that I’ve missed to account for source strengths in OpenMC?
Thanks,
Brody
Hi Brody,
Yes, you are right about the source strength. I agree that the proper thing to do would be to have the estimators in the problem multiplied by the sum of the source strengths which we are not currently doing. I’ll create an issue on github to track this and will think about the best way to handle it in the meantime. One simple thing we could do is to multiply the total tally scores by the sum of the source strengths at the time tally realizations are accumulated; that way, we don’t need to keep multiplying by the strength or change the particle weights.
Best,
Paul