ACER doesn't always respect the desired temperature tempd

[paulromano]

I've run into what I believe is a bug in NJOY when generating data at multiple temperatures. When an ENDF tape (produced by BROADR) is fed into ACER, the tempd entry on card 8 is supposed to indicate which temperature is desired for the data written to the ACE file. However, I'm finding that for some evaluations, it seems to pick the wrong temperature. As an example, below is an input deck for processing Ag109 from ENDF/B-VII.1 at two temperatures, 293.6 K and 600 K. In the ACER section, it instructs it to use the data at 293.6 K but what ends up getting written is the data at 600 K. Note that the resulting ACE table claims the data is at 600 K, but if you compare the data to what's actually in the original reconstructed/broadened cross sections present on the ENDF tape, it is clear the data is from the wrong temperature.

NJOY input deck

reconr /
20 21
'ENDF/B-7.1 PENDF for  47-Ag-109 '/
4731 2/
0.001/ err
'ENDF/B-7.1:  47-Ag-109 '/
'Processed by NJOY'/
0/

broadr /
20 21 22
4731 2 0 0 0. /
0.001/ errthn
293.6 600.0
0/

acer /
20 22 0 26 27
1 0 1 .01 /
'ENDF/B-7.1:  47-Ag-109  at 293.6'/
4731 293.6
1 1/
/
stop

If I take the exact same input deck and run it on, e.g., Ag107 (with the appropriate MAT number), ACER produces the correct cross section in the resulting ACE file. I tried this same exercise on all evaluations in ENDF/B-VII.1 and found that this bug is observed for the following evaluations

Evaluations where bug is observed

n-022_Ti_046.endf
n-022_Ti_047.endf
n-022_Ti_048.endf
n-022_Ti_049.endf
n-022_Ti_050.endf
n-023_V_051.endf
n-027_Co_058.endf
n-032_Ge_070.endf
n-032_Ge_072.endf
n-032_Ge_073.endf
n-032_Ge_074.endf
n-032_Ge_076.endf
n-033_As_074.endf
n-033_As_075.endf
n-036_Kr_085.endf
n-037_Rb_086.endf
n-038_Sr_084.endf
n-039_Y_090.endf
n-040_Zr_092.endf
n-040_Zr_093.endf
n-040_Zr_095.endf
n-040_Zr_096.endf
n-042_Mo_095.endf
n-043_Tc_099.endf
n-044_Ru_101.endf
n-045_Rh_103.endf
n-046_Pd_105.endf
n-047_Ag_109.endf
n-047_Ag_111.endf
n-048_Cd_115m1.endf
n-050_Sn_113.endf
n-050_Sn_125.endf
n-051_Sb_126.endf
n-052_Te_132.endf
n-053_I_130.endf
n-054_Xe_131.endf
n-055_Cs_133.endf
n-056_Ba_133.endf
n-057_La_140.endf
n-058_Ce_136.endf
n-058_Ce_138.endf
n-058_Ce_139.endf
n-058_Ce_143.endf
n-059_Pr_141.endf
n-059_Pr_142.endf
n-060_Nd_142.endf
n-060_Nd_143.endf
n-060_Nd_144.endf
n-060_Nd_145.endf
n-060_Nd_146.endf
n-060_Nd_147.endf
n-060_Nd_148.endf
n-060_Nd_150.endf
n-061_Pm_151.endf
n-062_Sm_144.endf
n-062_Sm_147.endf
n-062_Sm_148.endf
n-062_Sm_149.endf
n-062_Sm_150.endf
n-062_Sm_151.endf
n-062_Sm_152.endf
n-062_Sm_153.endf
n-062_Sm_154.endf
n-063_Eu_153.endf
n-063_Eu_157.endf
n-064_Gd_152.endf
n-064_Gd_153.endf
n-064_Gd_154.endf
n-064_Gd_155.endf
n-064_Gd_156.endf
n-064_Gd_157.endf
n-064_Gd_158.endf
n-064_Gd_160.endf
n-065_Tb_160.endf
n-066_Dy_156.endf
n-066_Dy_158.endf
n-066_Dy_160.endf
n-066_Dy_161.endf
n-066_Dy_162.endf
n-066_Dy_163.endf
n-066_Dy_164.endf
n-067_Ho_166m1.endf
n-081_Tl_203.endf
n-081_Tl_205.endf
n-090_Th_232.endf
n-091_Pa_231.endf
n-091_Pa_233.endf

I'll also mention some other things that I tried:

• I reverted my version of NJOY back to 2016.8 and this behavior is still observed, so it doesn't appear to be a recent issue in NJOY
• I tried with more than two temperatures. For example, if I run BROADR to produce 300, 600, and 900 K and then have three runs of ACER with tempd to pick out each temperature, the resulting ACE files actually have data at 600, 900, and 900 K respectively (so the first temperature seems to be skipped).

I've put together a Jupyter notebook that produces plots comparing the cross sections in the ENDF tape produced by BROADR and corresponding ACE files so you can visually see that the cross section (MT=2) is wrong:
https://gist.github.com/paulromano/40a636d2a49f31a4382ff8a4524b53cf

[whaeck]

After some digging I think I know where this is coming from.

NJOY uses a lot of findf calls to move back to a piece of the ENDF file. This function will scan the file forward unless it sees that it is too far down the material, and go backwards if necessary. To do this, it relies on the MAT/MF/MT part of each line on the file and I think that things go wrong there.

This is what the end of the 293.6 K material for Ag109 looks like:

 1.700000+7 7.628580-3 1.800000+7 7.665270-3 1.900000+7 7.538500-34731 3849   14
 2.000000+7 6.909440-3                                            4731 3849   15
                                                                  4731 3  099999
                                                                  4731 0  0    0
                                                                  4731 0  0    1
                                                                     0 0  0    2
 4.710900+4 1.079690+2          2          0          0          04731 1451    3
 0.000000+0 0.000000+0          0          0          0          64731 1451    4
 1.000000+0 2.000000+7          1          0         10          74731 1451    5
 6.000000+2 1.000000-3          1          0          2         694731 1451    6

As we can see here, the FEND record after the last MF3 section appears twice. This is an issue that we have seen before in files where only MF3 data is linearised in RECONR. Evaluations that have MF12 data (or other data that gets linearised like MF10), does not exhibit this behaviour. I'd wager (disclaimer: not taking bets here) that every single evaluation that exhibits this temperature confusion issue will only have MF3 data linearised in RECONR.

I assume that fixing the duplicate FEND record issue in RECONR will resolve the issue.

[whaeck]

Correction: Ag109 has MF12 data but it does not get linearised. Ag107 on the other hand gets its MF12 data linearised in RECONR.

This seems to be because RECONR only linearises LO=1 data (multiplicities). LO=2 data (transition probabilities) do not get linearised in RECONR. Ag109 uses LO=2, while Ag107 is LO=1.

[paulromano]

Thanks for digging into this @whaeck. Sounds like it should be an easy fix, once you figure out where the bug actually is 😄

[jchsublet]

@paulromano @whaeck @kahlerac

Interesting, but I am not waging on the actual bug, is it one? and foreseen solution. Yes some BROADR tapes have double FEND at the end of all the MF=3 temperatures they contains and this would confuse ACER? GROUPR and THERMR as well? exemplified on some reactor relevant targets for ENDF/B-VII.1 evaluations, quid for ENDF/B-VIII.0? other libraries?

One must ask: why feeding ACER with a multi-temperature BROADR tape? when it can only handle one temperature at a time? I investigated the past and never used pendf tape that contains more than one temperature for ACER, GROUPR yes, Bob’s spell? and may be some reading in LA-UR-12-27079 https://mcnp.lanl.gov/pdf_files/la-ur-12-27079.pdf. Removing the duplicate FEND in the Ag109 BROADR pendf and running two ACER requesting 293.6 and 600.0 in sequence stills lead to the same temperature output, although the ace.dir files contain the requested temperature!

[paulromano]

why feeding ACER with a multi-temperature BROADR tape?

This is how we generate multitemperature HDF5 libraries for OpenMC. If I want 10 temperatures, rather than running NJOY 10 times separately, I do a single run with all temperatures listed and run ACER 10 times as part of that to get 10 different ACE files (which then get combined into a single .h5 file).

[whaeck]

Lucky for us at LANL, we generate one temperature at a time so we never use a multi-temperature PENDF file. Regardless of this fact, this issue needs to be fixed asap in my opinion. NJOY is versatile as a tool, but sometimes the versatility leads to things like this.

Anyway, I have fixed the duplicate FEND records in the PENDF files coming out of RECONR (they were indeed due to MF12 linearisation) but it has not fixed the issue. ACER still picks up the 600 K data. The fix/acer-temp contains these changes.

So far I have been able to determine the following:

• the correct temperature is being used in convr (which looks up MF12 data)
• once unionx does a findf(matd,2,151,nin) or findf(matd,3,1,nin), we are looking at the wrong temperature.

It seems that findf still has issues with navigating the file even after the FEND fix. I'll continue looking into this to figure out what is causing this.

[jchsublet]

Little to do with luck, just LANL experience with NJOY. It does make sense to feed ACER with unionised MF3/MF12 mts tape, if 10 or even more temperatures are stored on the same tape this could prove challenging, it all depends when the grid union is made.

@paulromano what difference do you see in looping 10 temperatures reconr-broadr (with bootstrap if you want), store the single temperature pendfs, then 10 acer (as LANL) them a single .h5 (a very efficient one)

One can even think further than that, as the others MFs are temperature agnostic https://www-nds.iaea.org/Tendl2019/ could also be stored already tabulated ready for Monte Carlo sampling

[whaeck]

I think I fixed it. The issue arises when the PENDF tape is left at the end of the FEND record of MF3 in convr. When findf is called after that, this function will read the NEXT line before doing anything else - and that line is a MEND record. As a result, findf will read another line which would be the first line of MF1 MT451 of the NEXT material when there is only MF3 data in the PENDF file.

A simple skiprz call in strategic locations solves the issue (to ensure that the tape stays on a SEND record instead of a FEND record prior to calling findf).

fix/acer-temp has updated code, and a test to verify that it functions as advertised (using the input file provided by Paul Romano).

[paulromano]

@whaeck Just gave your fix/acer-temp branch a try on one of my full processing scripts and looks like the problem is fixed 🎉 Thanks so much for looking into this!

[whaeck]

This is now in the develop branch, which will be released soon so I'm closing the issue.