njoy / acetk

Toolkit for working with ACE-formatted data files

NJOY2016

The NJOY Nuclear Data Processing System is a modular computer code designed to read evaluated data in ENDF format, transform the data in various ways, and output the results as libraries designed to be used in various applications. Each module performs a well defined processing task. The modules are essentially independent programs, and they communicate with each other using input and output files, plus a very few common variables.

Documentation

The user manual for NJOY2016 can be found here: NJOY User Manual (pdf).

Release and development versions

For the latest version of NJOY2016 and an overview of the latest changes, please see the Release Notes or the release page.

The latest release version of NJOY2016 can always be found at the head of the main branch of this repository and every release is associated to a release tag. New versions are released on a regular basis (we aim to provide updates at least every three months). The latest development version of NJOY2016 containing the latest updates and changes can be found in at the head of the develop branch. This development version should be used with caution.

Installation

Prerequisites:

The following are the prerequisites for compiling NJOY2016:

• git
• cmake 3.15 or higher
• a Fortran 2003 compliant compiler such as gcc-7 or higher

Note: gcc-11.3 has been known to produce an internal compiler error while compiling NJOY2016, so as a result this specific version of gcc is not supported. Other versions of gcc (version 7 or higher) seem to be capable of compiling NJOY2016.

Instructions:

To compile the latest NJOY2016 version, you can use the following instructions:

git clone https://github.com/njoy/NJOY2016.git
cd NJOY2016
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ../
make -j8

The above instructions will produce a release build consisting of a dynamic library and dynamically linked executable. To compile a static version (i.e. the executable is not a dynamically linked executable), the cmake command shown above should be replaced with the following cmake command:

cmake -DCMAKE_BUILD_TYPE=Release -Dstatic_libraries=ON
      -Dstatic_njoy=ON -DCMAKE_EXE_LINKER_FLAGS=-static ../

When you have already cloned the NJOY2016 repository and wish to update to the latest version, you can use the following instructions (inside the build folder):

git pull
make -j8

Module overview

• NJOY directs the flow of data through the other modules and contains a library of common functions and subroutines used by the other modules.
• RECONR reconstructs pointwise (energy-dependent) cross sections from ENDF resonance parameters and interpolation schemes.
• BROADR Doppler broadens and thins pointwise cross sections.
• UNRESR computes effective self-shielded pointwise cross sections in the unresolved energy range.
• HEATR generates pointwise heat production cross sections (KERMA coefficients) and radiation-damage cross sections.
• THERMR produces cross sections and energy-to-energy matrices for free or bound scatterers in the thermal energy range.
• GROUPR generates self-shielded multigroup cross sections, group-to-group scattering matrices, photon-production matrices, and charged-particle cross sections from pointwise input.
• GAMINR calculates multigroup photoatomic cross sections, KERMA coefficients, and group-to-group photon scattering matrices.
• ERRORR computes multigroup covariance matrices from ENDF uncertainties.
• COVR reads the output of ERRORR and performs covariance plotting and output formatting operations.
• MODER converts ENDF "tapes" back and forth between ASCII format and the special NJOY blocked-binary format.
• DTFR formats multigroup data for transport codes that accept formats based in the DTF-IV code.
• CCCCR formats multigroup data for the CCCC standard interface files ISOTXS, BRKOXS, and DLAYXS.
• MATXSR formats multigroup data for the newer MATXS material cross-section interface file, which works with the TRANSX code to make libraries for many particle transport codes.
• RESXSR prepares pointwise cross sections in a CCCC-like form for thermal flux calculators.
• ACER prepares libraries in ACE format for the Los Alamos continuous-energy Monte Carlo code MCNP.
• POWR prepares libraries for the EPRI-CELL and EPRI-CPM codes.
• WIMSR prepares libraries for the thermal reactor assembly codes WIMS-D and WIMS-E.
• PLOTR reads ENDF-format files and prepares plots of cross sections or perspective views of distributions for output using VIEWR.
• VIEWR takes the output of PLOTR, or special graphics from HEATR, COVR, DTFR, or ACER, and converts the plots into Postscript format for printing or screen display.
• MIXR is used to combine cross sections into elements or other mixtures, mainly for plotting.
• PURR generates unresolved-resonance probability tables for use in representing resonance self-shielding effects in the MCNP Monte Carlo code.
• LEAPR generates ENDF scattering-law files (File 7) for moderator materials in the thermal range. These scattering-law files can be used by THERMR to produce the corresponding cross sections.
• GASPR generates gas-production cross sections in pointwise format from basic reaction data in an ENDF evaluation. These results can be converted to multigroup form using GROUPR, passed to ACER, or displayed using PLOTR.

License and Copyright

This software is distributed and copyrighted according to the LICENSE file.

acetk's Issues

ContinousEnergyTable secondary particle block retrieval does not range check the index

Secondary particle blocks like SIGH, etc. do not perform an index range check in DEBUG mode contrary to what the doxygen documentation tells us. Probably an oversight on my part when I refactored that part of the code.

In addition, we should also provide access functions for each of the vectors with these blocks (this would make copying over the data easier - no need to put everything into a vector yourself).

Config files not generated

when calling find_package and pointing to a newly installed ACEtk, I get the following:

By not providing "FindACEtk.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "ACEtk", but
CMake did not find one.

Could not find a package configuration file provided by "ACEtk" with any of
the following names:

ACEtkConfig.cmake
acetk-config.cmake

Add the installation prefix of "ACEtk" to CMAKE_PREFIX_PATH or set
"ACEtk_DIR" to a directory containing one of the above files. If "ACEtk"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (

Ambiguous interface in LAW=4 and LAW=67 data

          These are energies, not cosines.

Originally posted by @cjosey in #46 (comment)

Use enumerator values where possible

[design question, future]
Should these return enums or similar instead?

Originally posted by @cjosey in #49 (comment)

Support for version 2.0.0 header

We need to have support for 2.0.0 header. I know the specification may not have been well written, but there are files in "the wild" that use this header and therefore needs to be implemented.

16 isotopes in Lib80x give error when trying to load ContinuousEnergyTable

The following 16 isotopes in Lib80x (.00c) give the error "DLW multi-law - currently not implemented" when trying to load them with ACEtk.ContinuousEnergyTable.from_file():

B/5010.800nc
O/8017.800nc
F/9019.800nc
Na/11022.800nc
Na/11023.800nc
Ar/18036.800nc
Ar/18038.800nc
Co/1027058.800nc
Ba/56140.800nc
Ta/73182.800nc
Ra/88223.800nc
Ra/88224.800nc
Ra/88225.800nc
Ra/88226.800nc
Am/1095244.800nc
Am/95244.800nc

The remaining 540 isotopes in Lib80x load just fine.

ACEtk input examples

I am trying to use ACEtk to perturb some ace files but can't seem to find input examples. The one here (https://mcnpx.lanl.gov/pdf_files/TechReport_2022_LANL_LA-UR-22-30716_KleedtkeHaeckEtAl.pdf) didn't work after some modifications.

Here is my input so far, please take a look.

import sys
sys.path.append(r"/mnt/c/Users/bamidele/Downloads/ACEtk/build")
import ACEtk

table = ACEtk.ContinuousEnergyTable.from_file( '/mnt/c/Users/bamidele/Downloads/endf_b80_ace/4009.800nc' )

mt_rxn_index = table.MTR.reaction_numbers.to_list()

mt_number = 16
index = table.MTR.index(mt_number)
mt_xs_data = table.SIG.cross_section_data(index)
mt_xs_data_values = mt_xs_data.cross_sections.to_list()
energy_grid = table.ESZ.energies.to_list()

disap_xs_data_values = table.ESZ.disappearance.to_list()
total_xs_data_values = table.ESZ.total.to_list()
perturbed_energy_indices = list(range(1,len(energy_grid)))

perturbation_fraction = 0.2

manual perturbation of ACE file, perturb xs values by some amount

for k in perturbed_energy_indices:
a = mt_xs_data_values[k]
b = mt_xs_data_values[k] * perturbation_fraction
difference = b - a
mt_xs_data_values[k] = b
disap_xs_data_values[k + mt_xs_data.energy_index] = disap_xs_data_values[k + mt_xs_data.energy_index] + difference
total_xs_data_values[k + mt_xs_data.energy_index] = total_xs_data_values[k + mt_xs_data.energy_index] + difference

create new SIG block end ESZ block with perturbed values

new_xs_data = ACEtk.CrossSectionData( mt_xs_data.energy_index, mt_xs_data_values )
old_SIG = [ table.SIG.cross_section_data(i) for i in range( 1, table.NTR + 1 ) ]
old_SIG[table.MTR.index( mt_number ) - 1] = new_xs_data
new_SIG = ACEtk.CrossSectionBlock( old_SIG )
new_ESZ = ACEtk.PrincipalCrossSectionBlock( energies = table.ESZ.energies.to_list(), total = total_xs_data_values, disappearance = disap_xs_data_values, elastic = table.ESZ.elastic.to_list(), heating = table.ESZ.heating.to_list() )

save perturbed ACE info to new ace file

new_Table = ACEtk.ContinuousEnergyTable( z = table.Z, a = table.A, header = table.header, esz = new_ESZ, nu = table.Nu, dnu = table.DNU, mtr = table.MTR, lqr = table.LQR, sig = new_SIG, ang = table.AND, dlw = table.DLW, bdd = tableBDD, dned = table.DNED )
new_Table.to_file( "4009_plus.ace" )

Photofission neutron yield information not found for Am-241

Using the ACEtk features/photonuclear branch, secondary particle information for neutrons released from fission (MT=18) are not found for Am-241 (ZA=95241). From the ENDF file, it is expected that Am-241 would have both multiplicity (MT=452) and energy distribution (MF=5) for photofission neutrons.

Example script:

import ACEtk

tables = ACEtk.PhotonuclearTable.from_concatenated_file("xmc/endf7u")

for table in tables:
        if table.reaction_number_block.has_MT(18):
            print("{:} has MT=18".format(table.zaid))
            rb = table.secondary_particle_reaction_number_block(1)
            if rb.has_MT(18):
                print("   fission neutrons present")
            else:
                print("WARNING: {:} does not have fission neutrons".format(table.zaid))
            rb = table.secondary_particle_reaction_number_block(2)
            if rb.has_MT(18):
                print("   fission photons present")
            else:
                print("WARNING: {:} does not have fission photons".format(table.zaid))

Example output:

92235.70u has MT=18
   fission neutrons present
WARNING: 92235.70u does not have fission photons
92238.70u has MT=18
   fission neutrons present
WARNING: 92238.70u does not have fission photons
93237.70u has MT=18
   fission neutrons present
WARNING: 93237.70u does not have fission photons
94239.70u has MT=18
   fission neutrons present
WARNING: 94239.70u does not have fission photons
94240.70u has MT=18
   fission neutrons present
WARNING: 94240.70u does not have fission photons
95241.70u has MT=18
WARNING: 95241.70u does not have fission neutrons
WARNING: 95241.70u does not have fission photons

table.data.print()

Given a working Table, the following will not compile:

std::ostringstream oss;  
Table.print( oss ); 

I only saw testing for table.header.print()and it appears to work, but I am not certain that I am using table.print() correctly. I discovered this when working on feature/el03-temporary. Test will be pushed up shortly

issue with printing data - not sure if it is hidden chars or bad formatting...

I am trying to separate the elemental tables into individual files. I start with el03 and read each table one at a time and write them to a file labeled <z*1000>.el03

I can read and write all elements in el03 file with no problem when they have only a single isotope listed in IAZW section. For example, the 43000.el03 table looks like:

43097 96.073885 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000

However, starting with 44000.el03 something is amiss between reading from the el03 file and writing to the individual file 44000.el03. This is what you would see for 44000.el03 in the el03 file:

44000.03e 100.201894 .000000 06-06-98

44096 95.083699 44098 97.064229 44099 98.056283 44100 99.045987
44101 100.038748 44102 101.028935 44104 103.012819 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000

After writing to a separate 44000.el03 file you will find the following:

44000.03e 100.201894 0.0000E+00 06/06/98

4409695.08369900 4409897.06422900 4409998.05628300 4410099.04598700
44101*********** 44102*********** 44104*********** 0 0.00000000
0 0.00000000 0 0.00000000 0 0.00000000 0 0.00000000
0 0.00000000 0 0.00000000 0 0.00000000 0 0.00000000

Duplicate Writing of MT Number

I'm looking to zero out the inelastic collisions of U235. I've noticed that when changing MT=59 in the CrossSectionBlock, MT numbers will be altered in ways I don't believe it should.

I've uploaded an example as a gist here

You can see that 16 is removed, and 15 is added, in the reaction numbers, and additionally a duplicate 58 has been added.

In another script, when I go to read MT=59 in this resulting edited cross section file, I will get an error of "[error] The requested reaction number MT59 is not present" despite it appearing in the list of MT numbers.

This is using the ENDF data distributed with MCNP6.2, which I can attach or email privately if needed.

If I try to load this cross section in MCNP, I will get the following error,

 Expire parameter is 
 error 2 in  92235.80c of cross-section file xdata/endf71x/u/92235.710nc

 bad trouble in subroutine sread of xact                              

 error 2 in  92235.80c of cross-section file xdata/endf71x/u/92235.710nc

Set ZA according to LANL rules?

[Future work - documentation]
It doesn't need to be here, but it may be worth documenting the historical convention on handling metastables, namely:

1. The constructor arguments for Z and A are unmodified by S. Tc99m should not have A = 499.
2. The ZAID should be ZZZ[AAA + 300 (S > 0) + 100 S].NNx.
3. Am242m1 and Am242 are swapped (LANL convention - NNDC doesn't swap).

You can rightfully argue that the responsibility is on my team's side to document this. I intend to do so very soon. I just thought it would be easy for someone to have no idea about this weirdness if they're only working on this side.

Originally posted by @cjosey in #48 (comment)

factory method for making ACEtk::Table

Would be nice to hide to following in the body of a factory method:
auto contents = njoy::utility::slurpFileToMemory( filename );
njoy::ACEtk::State< std::string::iterator > s{ 1, contents.begin(), contents.end() };
auto table = Table( s );

e.g.
auto table = njoy::ACEtk::make< Table >( aceFileContaingTable );

KalbachMann is never used for photons?

Verify if Kabach-Mann is ever used for photons. If not, the numberDiscretePhotonLines() function should not even be in the interface.

Pybind11 version 2.6.1 does not support Python 3.11

Continuous integration using GitHub Actions has started to fail on MacOS 11 since last week, most likely following an update to the runners. That update seems to have installed Python 3.11 instead of a lower version.

As a result, all GitHub Actions on MacOS have started to fail automatically with errors like this:

Run make -j2
[  2%] Building CXX object CMakeFiles/ACEtk.python.dir/python/src/ACEtk.python.cpp.o
[  2%] Building CXX object src/ACEtk/ContinuousEnergyTable/test/CMakeFiles/ACEtk.ContinuousEnergyTable.test.dir/ContinuousEnergyTable.test.cpp.o
In file included from /Users/runner/work/ACEtk/ACEtk/python/src/ACEtk.python.cpp:2:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/pybind11.h:45:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/attr.h:13:
/Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/cast.h:446:36: error: member access into incomplete type 'PyFrameObject' (aka '_frame')
                "  " + handle(frame->f_code->co_filename).cast<std::string>() +
                                   ^
/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11/pytypedefs.h:22:16: note: forward declaration of '_frame'
typedef struct _frame PyFrameObject;
               ^
In file included from /Users/runner/work/ACEtk/ACEtk/python/src/ACEtk.python.cpp:2:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/pybind11.h:45:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/attr.h:13:
/Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/cast.h:448:29: error: member access into incomplete type 'PyFrameObject' (aka '_frame')
                handle(frame->f_code->co_name).cast<std::string>() + "\n";
                            ^
/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11/pytypedefs.h:22:16: note: forward declaration of '_frame'
typedef struct _frame PyFrameObject;
               ^

No way to specify MAT or Source in Header

There is a nice constructor for the Table::Header, but no way to specify the (optional) MAT and Source.

Implicit conversion issue

The following error occurs:

error: call to member function 'floor' is ambiguous

With the following:

constexpr auto mev = mega(electronVolt);
auto myA = A{...}
auto result = myA.floor(12*mev)

where:

struct A{
  constexpr auto mev = mega(electronVolt);
  constexpr auto cm = centi(meter);
  constexpr auto cc = cm*cm*cm;  
  using DenT = decltype(1.0/cc);
  using TempT = decltype(1.0*mev);

  auto floor(DenT density) const {/*details*/}
  auto floor(TempT temperature) const {/*details*/}
};

Resolve error by explicitly passing a double:

auto result = myA.floor(12.0*mev) // 12 -> 12.0

Unable to read MCNP6 xsdir files: Expected 'datapath'

When attempting to read a valid MCNP6 xsdir file with ACEtk.Xsdir.from_file(...), ACEtk errors out with the error text:

[error] Expected 'datapath' but found '#-------'

No xsdir files distributed with MCNP6.2 or 6.3 contain the expected 'datapath' string, at least not in my data directories. ACEtk should probably not error out in these cases, but set an appropriate default value based on the data directory structure of MCNP (probably datapath = "."; I guess?).

---

EDIT: Attempting to modify an MCNP6 xsdir file to be compatible with what ACEtk expects reveals some additional problems:

• ACEtk is not able to handle the comment character #, and any comment line will cause an error: Something went wrong while reading an xsdir entry
• ACEtk is not able to handle end-of-file and throws the error Expected an additional line but found the end of stream. This occurs even if there is no blank line at the end of the xsdir file; with two or more blank lines at the end the error reverts to Something went wrong.... My suggestion here would be to process the input file stream one line at a time (by using std::getline and feeding the result into a ``std::stringstream` after validating; this seems convoluted but is more reliable) instead of trying to read XsdirEntry objects directly from the file stream. This allows trimming and checking for empty lines/EOF before attempting to build a XsdirEntry. Doesn't work with the program flow.

Redesign the NU block interface

The interface for the NU block was designed for the total and prompt nubar for the NU block. The delayed nubar from the DNU block is the same but the interface feels inappropriate. This is not a blocking issue but we should look into it before the entire ContinuousEnergyTable gets deployed for general use.

Undefined "Readonly properties" of DLW.energy_distribution_data()

Multiple "Readonly properties" of the DLW.energy_distribution_data() are not defined for the Lib80x Pu-239 ACE file. Despite multiple distributions being present, the number of interpolation regions, interpolation boundaries, and interpolation types are not defined.