search

njoy / NJOY2016

Nuclear data processing with legacy NJOY
https://www.njoy21.io/NJOY2016
Other
96 stars 86 forks source link

Trouble in 'skip6' routine for LAW=1 products with detailed energy-dependent multiplicity #283

Closed mattooca closed 1 year ago

mattooca commented 1 year ago

LLNL is testing a candidate evaluation generated by the YAHFC code and converted to ENDF-6 by FUDGE. The file causes trouble for the 'heatr' module, and it appears to be due to the detailed energy dependence for MT=91 and MT=102 outgoing photon multiplicities. For these reactions, the outgoing photon is stored in MF=6 with 198 points (MT=91) for the photon multiplicity. The outgoing distribution is then stored as an energy-angular distribution tabulated, LAW=1.

I think the problem may be related to the use of npage in tab1io (in endf.f90): the problem only shows up if the multiplicity is longer than 153 points, or npage / 2. It appears that skip6 reads the entire TAB1 multiplicity array, but then tries to use array(npage+1) as the start of the distribution data in tab2io, so it's trying to do an integer read on floating-point data.

This is happening with the latest NJOY2016 (pulled and rebuilt this morning). I have an ENDF file (and NJOY input) to demonstrate the problem, but the ENDF file is quite large. I'll try to cut it down and send a simpler example.

Here's the traceback:

...
 ---message from sixbar---no distribution for mt 91 particle 94239
At line 1002 of file /g/g16/mattoon1/apps/NJOY2016/src/endf.f90 (unit = 14, file = '/var/tmp/mattoon1/gfortrantmpiZn8nH')
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
#0  0x2aaaac478304 in formatted_transfer_scalar_read
        at /builddir/build/BUILD/gccspack/spack/var/spack/stage/gcc-6.1.0-xza55yneihu2sofzfspnhfsbnsobq53j/gcc-6.1.0/libgfortran/io/transfer.c:1363
#1  0x2aaaac478304 in formatted_transfer
        at /builddir/build/BUILD/gccspack/spack/var/spack/stage/gcc-6.1.0-xza55yneihu2sofzfspnhfsbnsobq53j/gcc-6.1.0/libgfortran/io/transfer.c:1994
#2  0x2aaaaaef96e9 in tablio
        at /g/g16/mattoon1/apps/NJOY2016/src/endf.f90:1002
#3  0x2aaaaaf01d12 in __endf_MOD_tab2io
        at /g/g16/mattoon1/apps/NJOY2016/src/endf.f90:372
#4  0x2aaaaaef47a6 in __endf_MOD_skip6
        at /g/g16/mattoon1/apps/NJOY2016/src/endf.f90:1453
#5  0x2aaaab05b163 in sixbar
        at /g/g16/mattoon1/apps/NJOY2016/src/heatr.f90:2782
#6  0x2aaaab066672 in nheat
        at /g/g16/mattoon1/apps/NJOY2016/src/heatr.f90:1655
#7  0x2aaaab0738e6 in __heatm_MOD_heatr
        at /g/g16/mattoon1/apps/NJOY2016/src/heatr.f90:375
#8  0x401c9a in njoy
        at /g/g16/mattoon1/apps/NJOY2016/src/main.f90:205
#9  0x401ef2 in main
        at /g/g16/mattoon1/apps/NJOY2016/src/main.f90:112
whaeck commented 1 year ago

I've bumped into this issue a few times already in different modules - or at least I think it is the same. NJOY2016.69 actually fixes this in GROUPR. The ENDF read routines do not read the entirety of TAB1 and LIST records by default. To do that, you need to do a "do while call moreio" after calling the tab1io and listio functions. In some modules this is not done rigorously - probably because it was assumed that the data was read in entirely anyway (e.g. Legendre coefficients were limited to just a few so no need to call moreio). While these assumptions have hold up, recent evaluations have started to break this. This is why - so far - we fixed GROUPR and ACER.

I could modify the ENDF read routines but I'm not a fan of that solution since those routines handle more than just reading data (they also copy, etc.) and the code is somewhat fragile because of that.

Anyway, with that explanation out of the way I'd like to ask for an input file and the evaluation that causes it so that I can confirm that it is what I think it is - and fix it by adding "do while call moreio" in all of the appropriate places.