GROUPR problems with photon production matrices

[wempleca]

We have encountered two problems with the GROUPR module related to calculation of photon production matrices. The first (easily resolved) involved a search for the group containing the lowest energy photon in subroutine getff (beginning at line 7139), where the search may find a group number larger than the number of photon energy groups and produce an out-of-bound array reference later in the subroutine.

The second was more profound and connected to the first. In subroutine getff, a value is assigned to the local variable econ, which is used in the search loop mentioned above, that is derived from an array eccn returned by subroutine getgyl. Subroutine getgyl assumes that the File 12 data in the evaluated data file does not have a final entry that contains incident neutron energy-dependent yields, and that the lowest energy photon produced by the neutron interaction may be obtained simply by grabbing the value EGk from the first entry on the TAB1 record. If the last entry does contain incident neutron energy-dependent data (LP=2), this returned value is 0.0 (which produces the first problem, as described above). Unfortunately, preventing the out-of-bounds array reference results in no photon production being produced for the offending neutron reaction. This is particularly problematic for nuclides such as N-14 in E7R0/E7R1/E8R0, where the neutron capture reaction (MT=102) produces no photons (the problem is generic for nuclides with an LP=2 section for the highest neutron energy section of File 12). This is obviously quite disruptive to our efforts to produce coupled multi-group neutron-gamma XS libraries for our transport codes.

I am attaching our input file for N-14. Feel free to contact me if additional information is required.

N014.inp.txt

[nathangibson14]

Thanks, @wempleca. I'll start looking into this. Are you getting segfaults or other errors on the first problem, or does it appear more subtlety?

I'll also look at the photon production matrices I have processed myself. I'm wondering if you've uncovered something that we all should be concerned about.

--Nathan

[wempleca]

Hi Nathan, Thanks for the quick response. For the initial case (out-of-bounds array reference), we did get an execution error from the system, but that was because we tend to build with the DEBUG option in cmake. In standard build mode, I would expect a segfault. We did not get any segfaults, errors, or any other messages when the gamma production matrices were not produced - just a blank space in the output and no data in the GENDF file. Best regards, Chuck [Logo Description automatically generated] Charles A. Wemple Senior Nuclear Engineer Studsvik Scandpower Inc. +1 208 270 3351 1070 Riverwalk Dr., Suite #150 Idaho Falls, ID 83401 USA From: Nathan A. Gibson ***@***.***> Sent: Monday, September 12, 2022 12:50 PM To: njoy/NJOY2016 ***@***.***> Cc: Charles Wemple ***@***.***>; Mention ***@***.***> Subject: Re: [njoy/NJOY2016] GROUPR problems with photon production matrices (Issue #258) Thanks, @wempleca<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwempleca&data=05%7C01%7Ccharles.wemple%40studsvik.com%7C8504f76616a7419ea8f408da94efa7d8%7C1b790d31b62c423ab9deba4d12ea718f%7C0%7C0%7C637986054275915245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kCM%2B68v475J2AUdhJn32mCubTyW68mkIdS%2BbMRav%2Boc%3D&reserved=0>. I'll start looking into this. Are you getting segfaults or other errors on the first problem, or does it appear more subtlety? I'll also look at the photon production matrices I have processed myself. I'm wondering if you've uncovered something that we all should be concerned about.

…

--Nathan - Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnjoy%2FNJOY2016%2Fissues%2F258%23issuecomment-1244154945&data=05%7C01%7Ccharles.wemple%40studsvik.com%7C8504f76616a7419ea8f408da94efa7d8%7C1b790d31b62c423ab9deba4d12ea718f%7C0%7C0%7C637986054275915245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u8yaLenm6mJeck81o%2F%2BPb%2BhFCY5b3Takz1yNJZ74G9s%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA26ASCDOXMITIH4U5YKKIILV553PDANCNFSM6AAAAAAQI7WMEM&data=05%7C01%7Ccharles.wemple%40studsvik.com%7C8504f76616a7419ea8f408da94efa7d8%7C1b790d31b62c423ab9deba4d12ea718f%7C0%7C0%7C637986054275915245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyL8mG3y38tJzKuJUpxGblbHHK8dpMpzJ9pZ1Yxer6U%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

________________________________ The information contained in this email message, including any attachments, contains or may contain proprietary and confidential information intended only for the addressee. It is furnished with the understanding that it is for the sole use of the addressee and may only be used for the purposes for which it has been delivered by Studsvik or its designee. The information contained herein shall not be copied, reproduced or transmitted to any other parties, nor shall it be used for any other purpose, without prior written consent of Studsvik. If you have received this email in error, please return it to the sender and destroy or otherwise permanently delete the copy received.

[jchsublet]

@nathangibson14 @wempleca

This caught my attention as the issue(s) seem to be subtle, there are not that many N014 files around, secondaries other than neutron are gaining some importance

a) the issue is not picked up, flagged nor noticed by acer checks; all seems fine when the gammas are transported, read through acer or not read by heatr

https://t2.lanl.gov/nis/data/endf/ebalVII.1/summary.html
https://t2.lanl.gov/nis/data/endf/ebalVII.1/n/14chk.pdf
N014chk.pdf on ENDF/B-VIII.0 page 43 to 46

b) the issue has also been noticed by heatr (card 2 gamma local=1) and when ask to do more like in the slightly modified input deck, looking at tape31 through viewr, no gamma heating below 20 MeV

N014mod.txt
tape31.pdf

This also resonate with some of the findings made in a recent TM on secondaries https://conferences.iaea.org/event/260/

[wempleca]

Additional information to consider - the following isotopes exhibit similar behavior for MT=102 photon production from E8R0:

N-14
F-19
Al-27
Cl-35
Cl-37
Cr-50
Cr-52
Cr-53
Cr-54
Xe-123
Ta-180
Ta-181
Re-185
Re-187

Most of these give partial production from low-energy neutron capture, but nothing for the higher energy neutron capture. This was not the case for NJOY2012; I am attaching our input and outputs for Cr-50 from both NJOY2012 and NJOY2016 for reference.
Cr050.inp.txt
Cr50out-2012.txt
Cr50out-2016.txt

[wempleca]

Attached are input and output files from NJOY-2016 for U235. Note the near total lack of gamma production.

U235.njoy.inp.txt
U235.njoy.out.txt

[Ambr0K]

We've also encountered on something similar with FENDL3.2b processing, using custom group structure. For our needs, we seem to be getting good results for gamma transport part using igg=10 -> vitamin-j 42-group structure up to 50 MeV.