Add all releases and photon data to FENDL processing script

This issue is added in response to a requirement from @shimwell and @ukaea.

Currently the FENDL script allows the user to process data from FENDL-3.1a and FENDL-3.1d with FENDL-3.1d being the default. I am planning to add the option to download the following versions which are available from the IAEA Nuclear Data Service

FENDL-3.0
FENDL/MC-2.1
FENDL/MC-2.0

These versions are all available in the ACE format so the processing should be similar to the current implementation.

An additional requirement is to modify the scripts to include photo atomic data. This will be done by following the method in the generate_endf71.py script.

Thanks for letting us know of this planned work @SamPUG

The convert_nndc71.py script also has examples of generating photo atomic data.

Just a little history on the repo, Initially the convert_* scripts were designed to change .ace files to hdf5 and the generate_ scripts were used to convert *.endf files into hdf5. This boundary has been blurred somewhat as we have progressively added more options to scripts.

Good luck with this I am happy to review when you like

Having looked at FENDL 3.0 I noticed that the ace file for 19K-39 contains fields with "Inf" outputs. This causes a fatal error in the ace to hdf5 conversion process. In order to add the 3.0 release, this issue needs to be dealt with in some way. As the error is clearly in the ACE file, there is no recommendation that the hdf5 conversion process is changed to accommodate this.

My current proposal is to replace the v3.0 ace file with the v3.1a ace file. On the FENDL 3.1 page, there is information about the differences between v3.0 and v3.1a. The source files were not changed between v3.0 and v3.1a but a new version of NJOY (2012) was used and an upper kinematic limit for heating was applied.

Another option which I have looked at is using a new version of NJOY (2016) to generate the ace file using the same ENDF file and same NJOY input used to produce the v3.0 ace file. This is a more complicated process and will make the script take longer. I'm also think this method probably achieves the same end result as using the 3.1a ace file.

I am a little hesitant about modifying old releases. @shimwell do you have any thoughts on whats best here?

Another option is to ignore that particular file in the particular release.

Something similar was adopted for TENDL 2017 for the B10 isotope.

The script in the tendl case actually edits the ACE file but I wouldn't recommend this for your case.

How about using an if statement similar to this to just not include the isotope.

data/convert_tendl.py

Line 136 in ed6017e

    
           if library_name == 'tendl' and args.release == '2017' and filename.name == 'B010':

Perhaps just print a warning saying isotope not included due to inf within the ACE file.

As you say more recent releases of the FENDL ACE library work better and I guess that is due to improved testing

The conversion from endf file format would of course be a better solution but the processing times are longer and like you say this would make the convert_fendl script a lot larger.

In the future we should probably have a generate_fendl script which takes fendl endf files and uses NJOY functions to generate the ACE.

I've found that the FENDL-2.0 library has a significant number of nuclides which contain scattering data described by the Laboratory Angle-Energy Law (LAW=67 in ace format) which currently doesn't have a from_ace method. This means that these ace files cannot be converted.

This issue applies to the following nuclides: 'Be-9', 'Cr-50', 'Cr-52', 'Cr-54', 'Cu-63', 'Cu-65', 'F-19', 'Fe-54', 'Fe-57', 'Fe-58', 'H-2', 'Mn-55', 'Ni-58', 'Ni-60', 'Ni-61', 'Ni-62', 'Ni-64', 'Pb-206', 'Pb-208', 'Si-28', 'Si-29', 'Si-30'

This is quite a lot of the library, so I wonder if it is still worth including FENDL-2.0? @shimwell - what do you think?

So in the longer run it sounds like we will need this Laboratory Angle-Energy Law (LAW=67 in ace format). Any idea on the size of this law67 difficulty, is it too big to include?

This would require an implementation in OpenMC itself. We never bothered implementing this particular ACE scattering law because we never actually encountered any data files that use it. It probably wouldn't be terribly difficult to implement, but it's not a high priority for any of my projects. I would welcome a PR if any of you wanted to implement it (and would be happy to point you in the right direction as far as where it would fit in).

I think including the law would be a reasonably large task for me personally as the energy distribution processing is not something I am familiar with. Perhaps it would be best for me to leave FENDL-2.0 out for now and raise a separate issue to be picked up if LAW=67 is included at a later date?

That seems like the most sensible thing to do, but I'll let @shimwell have the final word since he's the boss :)

Yep that all sounds great to me.