NJOY2016.57 88-Ra-226g.jeff33 parsing error

[njchoi]

Hello.
Thank you for the replies in the ENDF/B-VIII.0 B10 issue before.
This time I brought an issue regarding JEFF-3.3.
Followings are the input I used and a segment of the output ACE file.
The processing finishes normally, but a strange value is observed (2.12448227712-322) and my ACE parser breaks down.
It is not even in the proper scientific notation.
This is located in the NU block of the 6th delayed neutron precursor group.
Could you please take a look at it?
Many thanks in advance!

reconr
20 21/
'pendf tape for 88-Ra-226g.jeff33'/
8834 0/
.001/
0/
broadr
20 21 22/
8834 1/
.001/
1800/
0/
acer
20 22 0 23 0/
1/
'reprocessed from 88-Ra-226g.jeff33'/
8834 1800/
/
/
stop

[paulromano]

NJOY does occasionally produce values that have a three-digit exponent. When this happens, the ACE file written will omit the 'e' in the exponential notation. This does cause pain if you're writing an ACE parser -- I know from first-hand experience. You can take a look at I did in OpenMC to handle this case here:
https://github.com/openmc-dev/openmc/blob/develop/openmc/data/ace.py#L408-L417

^That may help if you're writing Python. For a solution in C, see here:
https://github.com/openmc-dev/openmc/blob/develop/openmc/data/endf.c

Note that the ENDF format itself does allow numbers in exponential notation to be written without the 'e' 🤦

[njchoi]

Thank you, Dr. Romano. That's a new information for me and the references will be helpful.
But even considering the exponent format problem, the value does not seem to be physical.

[paulromano]

Yes, to me it looks like an uninitialized value (which often tend to manifest as a value very close to zero as you have there). The NJOY devs will have to weigh in on what the real culprit here might be.

[jchsublet]

@njchoi @paulromano numerical issues in Ace are always interesting thanks for bringing this one up, but if one first take a look at the source in that case Ra226 1455, all fits into place, the wrong places in that case

0.000000+0 0.000000+0 0 0 1 08834 1455 2
1.000000+1 8834 1455 3

One group !! when it should contains 6 to be consistent with 5455. Try with

0.000000+0 0.000000+0 0 0 6 08834 1455 2
1.332900-2 3.051000-2 1.151600-1 2.974000-1 8.476600-1 2.879600+09440 1455 3

This error will happen in more targets (for ENDF/B-VIII.0)

outAm240:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outBk245:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outBk246:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outBk247:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outBk248:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCf246:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCf248:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCf253:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCm240:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCm244:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outCm247:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outNp234:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outNp235:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outPa229:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outPa230:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outPu237:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outPu246:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outRa223:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outRa224:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outRa225:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outRa226:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups
outTh231:MF1 MT455 claims 1 delayed neutron groups, but MF5 MT455 claims 6 groups

Acer, always has been too merciful to evaluator, library assembler, thank to the commendable spirit of his father, this may change with the custodian

[njchoi]

So is this a data bug rather than a software bug?

[jchsublet]

Most definitely, the nuclear data is inconsistent, the ENDF-6 format frame not obeyed. Since this is trivial to correct or get it right, why should the processing software developer provide for even a warning?

[kahlerac]

With regard to the presence or absence of "e" when writing/reading a real number in scientific notation ... it is a feature of Fortran that ENDF evaluators have taken advantage of for decades. You can also have a real number with embedded blanks that are treated as zeroes, say 1.________+_0 for unity (I've used underscore to simulate the "blanks") and if properly positioned will be read with a Fortran e11.0 format specifier. It's not seen so much in modern files but if you happen to have access to older (say ENDF/B-III or -IV) you'll see it used all over the place. Skip

…

On Thu, Jun 4, 2020 at 11:47 AM jchsublet ***@***.***> wrote: Most definitely, the nuclear data is inconsistent, the ENDF-6 format frame not obeyed. Since this is trivial to correct or get it right, why should the processing software developer provide for even a warning? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHJISJR5AAIARBKY56B7XTRU66YZANCNFSM4NSGPJJQ> .

-- Dr. A. C. (Skip) Kahler Kahler Nuclear Data Services, LLC kahler3ac@gmail.com +1 321 368 3645

[jchsublet]

@kahlerac not sure I get the above remark or did I missed some-thing? I do not see any issue with the "e" but more with 1 group declared in 1455, when 6 spectra are in 5455, for my palate, may be too French, 6 groups with timing should be declared in 1455, the two lines proposal

[kahlerac]

Agreed that my comments on presence or absence of "e" are unrelated to inconsistent delayed neutron group number. I was responding to @paulromano's initial reply to @njchoi where he stated that omitting the "e" in scientific notation was an ENDF feature whereas its a Fortran language feature. And it's not just seen in ENDF-formatted files, I've seen the feature utilized in EXFOR data tables also, for example. Skip

…

On Thu, Jun 4, 2020 at 1:38 PM jchsublet ***@***.***> wrote: @kahlerac <https://github.com/kahlerac> not sure I get the above remark or did I missed some-thing? I do not see any issue with the "e" but more with 1 group declared in 1455, when 6 spectra are in 5455, for my palate, may be too French, 6 groups with timing should be declared in 1455, the two lines proposal — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHJISJEK4GKRW2UTFUG5EDRU7LYTANCNFSM4NSGPJJQ> .

-- Dr. A. C. (Skip) Kahler Kahler Nuclear Data Services, LLC kahler3ac@gmail.com +1 321 368 3645

[paulromano]

Yes, it did originate in Fortran. My point was that the ENDF-6 formats manual explicitly allows e-less floats as well as floats with spaces interspersed, as you alluded to, so I would be careful to not say that it's only a Fortran language feature. If you are writing an ENDF parser in a language other than Fortran, you do need to account for this possibility to truly conform to what the ENDF manual says.