ENDF/B-VIII.0 n-005_B_010.endf processing error with NJOY2016.57

[njchoi]

Hello.

While processing n-005_B_010.endf in ENDF/B-VIII.0 with NJOY2016.57, I encountered an error.

Followings are the input I used and the log.

Not much information could be found about the error message.

May I ask what the error message means and why it occurs?

Many thanks in advance.

reconr
 20 21/
 'pendf tape for n-005_B_010.endf'/
 525 0/
 .001/
 0/
broadr
 20 21 22/
 525 1/
 .001/
 600/
 0/
acer
 20 22 0 23 0/
 1/
 'reprocessed from n-005_B_010.endf'/
 525 600/
 /
 /
stop

 njoy 2016.57  01May20                                       05/30/20 20:24:29
 *****************************************************************************

 reconr...                                                                0.0s

 broadr...                                                                0.2s

 acer...                                                                  0.5s

 ***error in change***Undefined law for dlwh block:   0

[nathangibson14]

Thanks for reaching out. I can confirm that I see this same error for your input. Using NJOY 2016.56 seems to give the same error, but NJOY 2016.55 does not. You could roll back to this older version until we track down what happened.

@whaeck Do you recognize this error?

[whaeck]

I know what this is, I added it. NJOY2016.56 now has more tests while writing the xss array to a file. The law dependent data (in the angular and energy distributions) are written using an if ..else if ... tree but laws that were not implemented during the write process would simply fall through (there was no "I don't know what this means"), potentially causing an xss array to be garbage. While it rarely will happen, it is often due to evaluation choices that ACER does not handle. ACER does not consider every LAWs or LANGs possible (because no evaluations existed that used them) so they were not implemented.

2016.56 also introduced a lot of other testing for xss array consistency. The xss array is littered with locators and these are now tested against the current position in the file. Any offset of a locator with respect to the current position will now be flagged. This can happen when the locator is calculated badly, or if there are gaps in the xss array (which is technically allowed).

The new development for the IAEA photonuclear files is due to a similar issue (evaluation option being used that was never used before), but for photonuclear ace files. The capability for neutron and charged particle ace files introduced in 2016.56 will be expanded to the photonuclear files (and all other ACE types at some point).

While I am not entirely sure that this is one of them (neutron ACE files are the most common files and omitted evaluator choices would have been picked up long ago), we need to get to the bottom of it.

[whaeck]

By the way: I would be hesitant to use 2016.55 as a workaround because it may be an undetected issue in older versions as well - at least until we know what's going on.

[njchoi]

Thank you for the replies. Would I have to be worried with that error if I'm only performing neutronics calculations? In fact, I know about DLW and DLWP blocks in the ACE format, but I have never read about DLWH block in manuals.

[whaeck]

DLWH is for charged particle production data, so if you're using neutrons only you should be safe with NJOY2016.55.

I may have an idea what the problem is. Under certain conditions, NJOY is incapable of calculating the recoil energy if the two fragments are both charged particles. This sometimes happens for light atoms and will cause a law=0 to be generated. I'l have a look.

[paulromano]

I'm wondering if #50 is related to this.

[whaeck]

Could be. It’s the same nuclide

[jchsublet]

@paulromano @whaeck Have a look at https://www.nndc.bnl.gov/endf/b8.0/errata.html where a correction for double count in B010 has been made, not all is always on the shoulder of the processing module or step

[jchsublet]

Add a go at it with the above and it worked with .57, but then I also remember that Caleb needed to merge the LANL correction from the above to the real B010 from ENDF/B-VIII. 0 as it was not done (the above correction) on his latest post to ENDF/B-VIII.0. You may want to interact with him prior to shifting the blame on NJOY

njoy 2016.57 01May20 05/31/20 09:57:07

---

reconr... 0.0s

broadr... 0.1s

acer... 0.3s

---message from ptleg2---negative probs found 20 for mt= 2 e= 1.650E+07

---message from ptleg2---negative probs found 15 for mt= 2 e= 1.700E+07 0.9s

---

Also the above message does not make sense, negative probs on B010, the nuclei is non-resonant !

[whaeck]

I probably shouldn't be resurrecting a discussion to just close it, but the main issue here is the evaluation. There is an errata on this nuclide and it resolve this issue: https://www.nndc.bnl.gov/endf-b8.0/errata.html