ERRORR processing issue for MF34 with multiple subsections

[whaeck]

A few of the ENDF/B-VIII.0 files have covariance data in MF34 that go beyond a single subsection (that is, not only P0 covariances) in the MT2 section. The ERRORR module crashes on these files because the use of a single section has been hardcoded.

A preliminary investigation of the source code has indicated that, when multiple subsections are present, the ERRORR module crashes when reading the covariance data from the ENDF file. The module loses itself in the ENDF file because it is improperly coded. A first try to correct the coding for reading the covariances appears to break the entire covariance processing.

The ERRORR module reads the covariance data for all types (MF32, MF33, MF34, ...) in a single block of code riddled with if statements that branch depending on the covariance data type instead of specific code blocks for each covariance type. Disentangling this coding will most likely be required to offer a permanent fix.

I will add an input file to illustrate this using one of the ENDF/B-VIII.0 files that has multiple MF34 subsections.

As a side note: ERRORR also appears to only handle MF34 MT2 and ignore any other MT sections that may be present. This is again a hard coded feature.

[whaeck]

This issue was "fixed" previously for Fe56 from JEFF3.3 (see test 46). The only caveat to give here is that the covariance matrix in the output is the one corresponding to the first subsection only. All other contributions seem to be ignored.

The following input file illustrates the issue using ENDF/B-VIII.0 U235 which still crashes (see issue #203): u235-mf34.txt

[whaeck]

First, a bit of an overview of what the covariance subsections look like.

For MF33, a subsection looks like this:

[MAT,33,MT/ XMF1, XLFS1, MAT1, MT1, NC, NI]CONT
<sub-subsection for n =1>
<sub-subsection for n =2>
-----------------------------
-----------------------------
<sub-subsection for n =NC>
<sub-subsection for n =1>
<sub-subsection for n =2>
-----------------------------
-----------------------------
<sub-subsection for n = NI>

For MF34, a subsection looks like this:

[MAT,34,MT/ 0.0, 0.0, MAT1, MT1, NL, NL1]CONT (MAT1=0)
[MAT,34,MT/ 0.0, 0.0, L1, L11, LCT, NI1]CONTa
[MAT,34,MT/ 0.0, 0.0, LS1, LB1, NT1, NE1/ {Data1}] LIST
----------------------------------
----------------------------------
[MAT,34,MT/ 0.0, 0.0, LSNI1, LBSNI1, NTSNI1, NENI1/{DataNI1}] LIST
----------------------------------
----------------------------------
[MAT,34,MT/ 0.0, 0.0, LNSS, L1NSS, 0, NINSS ] CONT
[MAT,34,MT/ 0.0, 0.0, LS1, LB1, NT1, NE1/ {Data1} LIST
----------------------------------
----------------------------------
[MAT,34,MT/ 0.0, 0.0, LSNINSS, LBNINSS, NTNINSS, NENINSS/ {DATANINSS}] LIST

Due to the intertwined code for the different MF covariance types, NJOY2016 reads these using common code based on what is in MF33. NJOY2016 will thus read first NC subsubsections followed by NI subsubsections. Between MF33 and MF34, the structure of the NI subsubsections are in common (MF34 also has an extra CONT record at the start of the subsection, which is read separately). MF34 does not have these initial NC subsubsections. However, the coding in NJOY2016 still assumes that an NC value is given in the MF34 data (around line 1952 of error.f90):

      call contio(nendf,0,0,scr,nb,nw)
      if (mfcov.eq.34.and.mth.eq.0) go to 660
      if (mfcov.eq.34) then
         mat1=mat2
         mt1=mt2
         ld=l1h
         ld1=l2h
      else
         mat1=l1h
         mt1=l2h
      endif
      if (mt1.eq.0) call error('covcal','illegal mt1=0.',' ')
      nc=n1h
      ni=n2h

Based on the structure given above, NJOY2016 will thus store the LCT value in nc and the NI value in NI. If LCT=0, than there is no issue here: there are no NC subsubsections present. This is the case for the previously mentioned Fe56 which has LCT=0. However, U235 does not. That evaluation has LCT=1 which NJOY2016 then interprets as NC=1 leading to the problem observed in issue #203.

[whaeck]

Replacing the last two lines of code given above by the following:

      if (mfcov.eq.34) then
         nc=0
         ni=n2h
      else
         nc=n1h
         ni=n2h
      endif

solves the problem since nc is always zero in MF34. The input file given above now runs to completion. The fix/endf80-mf34 branch fixes the this issue.

Not everything is perfect though: the ENDF/B-VIII.0 U235 evaluation still produces a zero covariance file. While the covcal routine does calculate the covariance matrix for each l,l1 pair only the first one is written to the output file in the covcal routine.

[whaeck]

Closing this, follow up in #205