ACER crashes on a temporary file when processing JENDL5 Eu143

[whaeck]

The following input file and evaluation file cause an error in the ENDF reading routines.

631470_JENDL5.02.input.txt
eu147

The issue appears to be similar to the issues we have seen before that can be solved by adding proper "do while moreio" but in this case, it does not appear to be related.

[whaeck]

What we know so far about this issue:

The issue seesm to happen in the acelcp function that generates the secondary particle data at the end of the XSS array (the SIGH, ANDH, DLWH, etc. blocks). The function uses a temporary tape with data copied over or transformed from the original ENDF file. In this case, the error happens while going over the secondary particles in MT5 when skip6a gets called.

The JENDL5 evalaution for Eu147 uses LAW=7 for the secondary particle data. As a result, this data gets transformed into a LAW=1 representation before being copied over to the temporary tape. This happens in the acefc.f90 file around line 2310 (in the topfil subroutine):

            else if (lf.eq.7.and.newfor.eq.1.and.no7.eq.1) then
               ! law=7 for newfor=1 -- convert the law7
               ! data into law1 format.
               call tab2io(nin,0,0,b,nb,nw)
               ne=nint(b(6))

The TAB2 after the multiplicity data gets read into the b array. This gets modified and written back to the temporary tape around line 2340:

                  ! fix up the tab2 for law1
                  if (ie.eq.1) then
                     b(3)=10+intmu
                     b(4)=intep
                     call tab2io(0,nout,0,b,nb,nw)
                     ncs(nxc)=ncs(nxc)+2
                  endif

The values of the b array indicate 47 incident energy points using an interpolation type of 22. After this point, the TAB2 does not get modified - or at least I think it doe not get modified.

Later on, in the acelcp subroutine, we loop over the secondary particles in an MF6 section around line 9350:

               ik=0
               idone=0
               do while (ik.lt.nk.and.idone.eq.0)
                  ik=ik+1
                  ll=1
                  lly=ll
                  call tab1io(nin,0,0,scr(ll),nb,nw)
                  izap=nint(c1h)
                  awp=c2h
                  law=l2h
                  ll=ll+nw
                  do while (nb.ne.0)
                     call moreio(nin,0,0,scr(ll),nb,nw)
                     ll=ll+nw
                  enddo

The tab1io function reads the multiplicity of the particle in question. If it is the particle we were looking for, stuff will happen. Otherwise, we'll just call the skip6a subroutine to skip the subsection for the current particle:

                  if (izap.ne.ip.or.law.ne.1) then
                     call skip6a(nin,0,0,scr,law)
                  else
                     call tab2io(nin,0,0,scr(ll),nb,nw)

Since the temporary tape converted to LAW=7, we need to follow the LAW=1 logic in the skip6a subroutine:

   else if (law.eq.1.or.law.eq.2.or.law.eq.5) then
      call tab2io(nin,nout,nscr,a(1),nb,nw)
      ne=n2h
      do ie=1,ne
         call listio(nin,nout,nscr,a(1),nb,nw)
         do while (nb.ne.0)
            call moreio(nin,nout,nscr,a(1),nb,nw)
         enddo
      enddo
   else if (law.eq.7) then

Here, just before the crash (while skipping over the MF6 MT5 subsection for deuterons), the number of incident energy points to skip over has become 48 (instead of 47) and the interpolation type has become 2 (instead of 22). Weirdly enough, the multiplicity data that was read before the skip6a function was called uses 48 incident energy points and interpolation type 2. Might be a memory issue?

The previous secondary particles that are skipped over have the same structure (multiplicity for 48 point, followed by TAB2 for 47 incident energy points) but do not cause this crash.

[whaeck]

@kahlerac Here's what I have so far.

[kahlerac]

Wim, I've procrastinated far too long on looking into this issue, but now that I have, let's go back to my June 26, 2022 email in the "Herter4171 JENDL5 issue" thread. The changes ("nw" to "nwb" in two locations) seem to resolve the current 147Eu processing issue also. Unfortunately my lack of GitHub experience meant they never made it beyond that email. Skip

…

On Wed, Mar 29, 2023 at 12:54 PM Wim Haeck ***@***.***> wrote: @kahlerac <https://github.com/kahlerac> Here's what I have so far. — Reply to this email directly, view it on GitHub <#293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHJISIW67AIUUXPK3RPHFLW6RSMZANCNFSM6AAAAAAWMEHHDM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Dr. A. C. (Skip) Kahler Kahler Nuclear Data Services, LLC ***@***.*** +1 321 368 3645

[whaeck]

Yes, that resolves the issue. I've put up a PR for it. Once we finish that one, we can go ahead towards a release. As mentioned in our meeting yesterday, we'll postpone the Li fix until you have had a thorough look at it.

[whaeck]

Resolved in NJOY2016.71