energy distribution for secondary alphas from reaction (a,n*)a

[jchsublet]

The below JENDL-NNL's modified a-Be009 file now run through acer processing, however although neutron emission spectral data exits, it sort of hangs there:

energy distribution for secondary alphas from reaction (a,n*)a (mt = 22) with 1 law(s)
law = 0 1st of 1 laws for reaction (a,n*)a
probability of law
nr = 0
ne = 0
e(i=1,ne) =
p(i=1,ne) =
data for law

Is it for me to put a more palatable/ acceptable to acer mf6/mt22 or a not (yet) programmed in acer case? I am open to suggestion

Be009.txt
Be009chk.pdf
outBe009.txt
inBe009.txt

[jchsublet]

I nearly forgot, this is definitely not a new issue as I tested the above, to get the same answer with NJOY99396, NJOY2012_0, NJOY12082 and last but no least NJOY2016.52

[whaeck]

This one looks interesting. The number of regions is equal to zero? I'll have a look at this one next.

[jchsublet]

@whaeck while there you may also look at https://www-nds.iaea.org/index-meeting-crp/TM%20FENDL/docs/IAEA.FENDL_meeting2019.SKwon_rev3.pdf slides 26, 27. This has a similarity in how to handle multiple neutron emission + residual (equal to incident) on charge particles, in this case d, while for the above I have a as incident

[whaeck]

So I digged into this one a bit further and I have a clear idea of what is going on.

This is an incident alpha file (other incident particles work in the same way) so acer will load all data for this incident particle in the acelod subroutine and construct the xss array as it goes. To do so, this subroutine will count the number of reactions it has to include in the mtr block. By default, this will include MT22 for incident alpha particles. So, if MT22 is defined, it will be in the MTR block and can thus have entries in the AND and DLW blocks (respectively angular and energy distributions). At this point, acelod has not verified which of these reactions actually produce the incident particle as well.

Once acelod has assigned the locators for all initial blocks up to the SIG block in the jxs array, it will determine which reactions out of the MTR block produce the incident particle (starting at line 5329 in acefc.f90). It does this by using hardcoded MT numbers, for each incident particle type. Again, MT22 is in that list to acelod expects to found outgoing alpha data for this reaction. So, if MT22 is present in the evaluation, the cross section for this reaction will be included in the SIG block but so will the angular and energy distributions in the AND and DLW blocks.

For the angular distribution data, things are easy: since MT22 is an MF6 reaction, the associated LAND entry is set to -1 so no angular distribution data is given. The AND block is written as expected.

On line 5838, acelod will go over the energy distributions. When it gets to MT22, it will call teh acelf6 subroutine to get the information and that is where things go wrong. This subroutine is defined on line 6986. In it, it will go over the various MF6 subsections and look for the incident particle (since we're trying to find the outgoing particles of the same type). It does this in a do loop on line 7049. However, it does not check if it has found this subsection.

The issue is that the MF6 MT22 section in this Be9 evaluation has no subsection for alpha particles. As a result, the xss array is malformed at this point leading to a "corrupt" ACE file.

[whaeck]

Continued from the previous comment.

The acelf6 subroutine goes over the various subsections and looks for the incident particle as the outgoing particle. It sets the number of subsections for this particle in the ik variable, so this value should be at least equal to 1 for the remainder of the subroutine to function normally. In multiple places, we see do-loops like do j=1,ik. So if the subsection is not found, these loops are not executed - and that causes the issue. The law=0 is simply an artifact of that: the section is actually not found and law is zero by default.

In short: the evaluator decided not to include outgoing alpha data into the MF6 MT22 section, and that causes the issue because acer assumes that for incident alphas, MT22 always has outgoing alphas. Knowing that MT22 is actually z,na, it is strange that the outgoing alpha is excluded from the MF6 section.

I have added a test to acelf6 to detect this in the future, and to gracefully exit. As a side note: the branch fix/acer-consis detects this problem as well when it tries to write the xss array since I added a test in there to detect laws that aren't implemented (in this case law=0).

See fix/acer-missing-particle for this fix.

[jchsublet]

@whaeck OK thank for the thorough insider knowledge, I should have guessed that the file was incomplete, so many are. So the ball is in my camp and I will had the necessary data blocks

We agree that this sequence has nothing to do with the fact that the emitted particle missing data also relates to the incident one? and lines 5362 (d), 5382(a) of acefc @53 ?

[whaeck]

@jchsublet This happens because the produced outgoing particle in this case is the same as the incident particle (a similar situation could occur for other incident particles). The code starting at around line 5332 goes over the different reactions that produce the incident particle, for each type of incident particle. If those reactions are present, acer will assume they are complete. These MT numbers are then added to the MTR block.

[whaeck]

Solved with #146