Closed whaeck closed 5 years ago
There are multiple ways to solve the issue:
The first option would be the cleanest as this is read for every iopt and izn, awn are transmitted to the various functions that handle the different iopt values. On the other hand, this would make card 8a obsolete and would break backwards compatibility.
The second solution would not break backwards compatibility. By adding an additional variable called niza on card 8 (default value set to 3), we would retain backwards compatibility and allow a user to add more values should he so desire.
This is actually a duplicate of #25, but glad to see it's receiving attention!
@paulromano I had a feeling I had already seen something like this before. I went over the issues but did not pay enough attention apparantly.
No worries. I would suggest just closing #25 since you've already elaborated on the problem much more here than my three sentence description.
One point remains to be resolved: what does the awn array mean for thermal scattering. If a user uses card4, we'll have values in the izn and awn array but we overwrite the values in izn array in acesix for thermal scattering data using iza01, iza02 and iza03 but we don't touch awn (in the proposed resolution I moved this outside of acesix).
I would surmise that awn is meaningless for thermal scattering - to be determined.
Done, merged #127
Card 8a on the ACER input allows a user to set the ZA values that go into the ACE file for a thermal scattering file. By default, NJOY limits these to 3 while the ACE format actually allows up to 16 values. This becomes an issue when one tries to specify the ZA values for a thermal scattering file such as ZrH or SiO2. Previously, these were added by hand as required.
This issue is related to an email received on the MCNP forum about a discrepancy between the ZA values in zr-zrh.80t, zr-h.20t and zr-h.30t.
By chaning the NJOY input to allow up to 16 values, we would avoid errors during the manual modification phase.