search

njoy / NJOY2016

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

Consideration of the scattering radius uncertainty (DAP) in ERRORR #326

Closed Pierresole closed 5 months ago

Pierresole commented 5 months ago

https://github.com/njoy/NJOY2016/blob/9adfc0898848b6864a71d3e7920d255ce45f7901/src/errorr.f90#L3176C32-L3176C32

Steps to Reproduce:

Launch ERRORR on the n-Pu-239 evaluation from ENDF/B-VIII (input at the end).

Modify DAP (Scattering Radius Uncertainty):

Observe Output: The output tapes produced (original DAP / modified DAP) shows no difference in the final covariance matrix, regardless of the DAP modification (simple "diff" Linux-command). Expected Behavior: The covariance matrix remains unaffected by changes in DAP, which is inconsistent with the expected behavior as per the NJOY manual.

If my comment make sense, I will continue with a potential solution :

Cause: In the code between lines 3175 and 3198, there's a loop from 1 to NLS (number of L-values as defined in MF32). However, for LRF=3, NLS is always zero in MF32, as there's no L-value segregation in this format. This might be leading to the issue where changes in DAP are not being accounted for in the covariance matrix calculation.

Suggested Fix: Instead of using NLS from MF32 in this section of the code, one may consider utilizing the NLS value from MF2. This modification would align with the expected behavior where changes in DAP should influence the covariance matrix.

moder
20 -25
reconr
-25 21
'94Pu239 - 0.0 K - B8'/
9437 0 0
0.001 0 0.01 5e-08
0 /
--
-- in in 0 out 0 0
-- mat grp wgt print rel
-- mprint temp
-- iread mf irespr legord ifissp efmean dap
errorr
-25 21 0 85 0 0
9437 1 2 1 0
1 0
0 33 1 3/
9/
1.000000e-5
0.100000e+3
0.200000e+3
0.300000e+3
0.400000e+3
0.500000e+3
1.000000e+3
1.500000e+3
2.000000e+3
2.500000e+3/
stop
whaeck commented 5 months ago

This is something we will have to look into to see what's going on. I'm currently still on vacation but I'll have a look as soon as I get back to work to see if there is a quick fix.

Pierresole commented 5 months ago

I took the liberty of closing the issue after realizing that the root of the problem lies maybe more in the specifics of the ENDF-6 format rather than in the ERRORR code itself. If you have the time, here is a precision on the situation :

In ENDF Manual : Remark : there are 2 NLS keys, hence the distinction NLS(MF2) and NLS(MF32) according to their File location.

If LCOMP=1, then NLS(MF32)=0 [...] (page.232)

If MLS=1, then DAP is assumed to be the uncertainty for all APLs ; (page.235)

In the last quote "all APLs" refers to NLS(MF2) ... right ?

In the current state ERRORR creates an array of size NLS(MF32) : should ERRORR be considering NLS(MF2) rather than NLS(MF32) ? The latter being often equal to zero leading to no DAP propagation.

In some evaluations where NLS(MF32) is set equal to NLS(MF2), ERRORR performs the propagation as expected. However, in other evaluations that strictly adhere to the ENDF manual, evaluators set NLS(MF32) to 0, leading to ERRORR not propagating the DAP.