njoy/endftk

Toolkit for reading and interacting with ENDF-6 formatted 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.

endftk's Issues

NT values for MF8 MT457 discrete spectra (decay data)

The procedures part of the ENDF manual MF8 MT457 states that NT can be 8. In the latest version/branch of ENDFtk, we verify if NT is equal to 4, 6 or 12.

We should verify and change the test function and the appropriate constructors.

ENDFtk.python: gcc-11 compilation error

Mac: CMakeFiles $ cat CMakeError.log
Performing C++ SOURCE FILE Test HAS_FLTO failed with the following output:
Change Dir: /Users/mparis/t5500/Research/code/endf/ENDFtk/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make -f Makefile cmTC_4173c/fast && /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/cmTC_4173c.dir/build.make CMakeFiles/cmTC_4173c.dir/build
Building CXX object CMakeFiles/cmTC_4173c.dir/src.cxx.o
/usr/local/bin/gcc-11 -DHAS_FLTO -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk -flto -fno-fat-lto-objects -std=gnu++17 -o CMakeFiles/cmTC_4173c.dir/src.cxx.o -c /Users/mparis/t5500/Research/code/endf/ENDFtk/build/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: '-fno-fat-lto-objects' are supported only with linker plugin
make[1]: *** [CMakeFiles/cmTC_4173c.dir/src.cxx.o] Error 1
make: *** [cmTC_4173c/fast] Error 2

Source file was:
int main() { return 0; }

$ ipython
Python 3.9.5 (default, May 4 2021, 03:36:27)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.24.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ENDFtk

ImportError Traceback (most recent call last)
in
----> 1 import ENDFtk

ImportError: dlopen(/Users/mparis/t5500/Research/code/endf/ENDFtk/build/ENDFtk.cpython-39-darwin.so, 2): Symbol not found: __ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
Referenced from: /Users/mparis/t5500/Research/code/endf/ENDFtk/build/ENDFtk.cpython-39-darwin.so
Expected in: flat namespace
in /Users/mparis/t5500/Research/code/endf/ENDFtk/build/ENDFtk.cpython-39-darwin.so

Feature : additional constructor to sections, files, materials

A constructor of the following type could be interesting for users (that includes me):

template< typename Iterator > section( Iterator& begin, const Iterator& end ) {
  try {
    long lineNumber = 0;
    HeadRecord head( begin, end, lineNumber );
    section( head, begin, end, lineNumber, head.MAT() );
  }
  catch ( ... ) {
    // handle exceptions
  }
}

Add ENDF speak to TAB1 and TAB2

This relates to using NBT, INT, etc.

Python bindings must have these added in the definitions.hpp file.

NBT and INT are not available as ENDF speak

This applies to TAB1 and TAB2 records

Members should be private/protected with getters and setters

In some parts of the ENDFtk source code, members of classes are put in the public part of the class. These should be made private/protected and getters and setters should be added instead.

This will also help with coherence in the code.

Building feature/offline Error

-- Using release repositories
-- 
-- -----------------------------------------------------------
-- 
-- catch-adapter
-- Git current branch: HEAD
-- Git commit hash: fb84b82ebf7a4789aa43cea560680cf745c6ee4f
-- 
-- -----------------------------------------------------------
-- 
-- -----------------------------------------------------------
-- 
-- hana-adapter
-- Git current branch: HEAD
-- Git commit hash: f58e8973c9a614dc4f3720b5581a762c61bdbb40
-- 
-- -----------------------------------------------------------
-- pybind11 v2.6.1 
CMake Warning at dependencies/range-v3-src/cmake/ranges_env.cmake:77 (message):
  [range-v3 warning]: unknown build type, defaults to release!
Call Stack (most recent call first):
  dependencies/range-v3-src/CMakeLists.txt:50 (include)


-- Found Doxygen: /usr/bin/doxygen (found version "1.8.5") found components: doxygen dot 
-- [range-v3]: C++ std=1z
-- Performing Test RANGES_HAS_CXXSTD
CMake Error in /workspace/ENDFtk-offline/bin/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Target "cmTC_657e6" requires the language dialect "CXX17" (with compiler
  extensions), but CMake does not know the compile flags to use to enable it.


CMake Error at /cmake/3.19.1/share/cmake-3.19/Modules/Internal/CheckSourceCompiles.cmake:89 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
 /cmake/3.19.1/share/cmake-3.19/Modules/Internal/CheckCompilerFlag.cmake:66 (cmake_check_source_compiles)
  /cmake/3.19.1/share/cmake-3.19/Modules/CheckCXXCompilerFlag.cmake:40 (cmake_check_compiler_flag)
  dependencies/range-v3-src/cmake/ranges_flags.cmake:16 (check_cxx_compiler_flag)
  dependencies/range-v3-src/cmake/ranges_flags.cmake:86 (ranges_append_flag)
  dependencies/range-v3-src/CMakeLists.txt:51 (include)


-- Configuring incomplete, errors occurred!
See also "/workspace/ENDFtk-offline/bin/CMakeFiles/CMakeOutput.log".```

Need MF=2/MT152

I need the ability to create an MF=2/MT=152 in a PENDF file.

Provide convenience interface for an an entire library

NT

TapeIdentification fails when input iterator is less than 80 characters.

Because the ENDF line numbers (NS) are now optional, the ENDF lines do not have to go all the way to 80 characters.

If I create a TapeIdentification object and pass it an iterator that is less than 80 character (say 75), then it throws an exception with a message Trouble reading Tail.

Here is a valid TPID Record (from ENDF/B-VIII.0 Beta4). Take everything between the single quotes.

' $Rev:: 1056     $  $Date:: 2017-01-26#$                             1 0  0'

Issue Building ENDFtk dev branch

@whaeck There should be a text file attached to show errors raised when building with gcc-7 and clang-8
error.txt

Can't specify C2 value on third CONT record of MF=1/MT=451

A PENDF file uses the C2 value on the third CONT record of MF=1/MT=451 to specify the temperature of the ENDF Material. There currently is no way to specify that either in a constructor or with a setter.

Should NXC in MF=1, MT=451 be allowed to be zero?

The NXC parameter in MF=1, MT=451 is "The number of records in the directory for this material." (See ENDF manual.) The ENDF manual does not require that there is a directory in MT=451.

Right now, a check is made to ensure that NXC > 0. Since the directory is not required, should this check be allowed to equal zero?

MF26 multiplicity should always be 1

The ENDF manual says that the multiplicities must always be 1, not just "normally one". Thus, it doesn't really make sense to require it as an input. I think the only value of this constructor would be to make a user specify the energy range and the law.

That said, maybe consistency with MF6 is desired? So maybe this is okay?

Originally posted by @nathangibson14 in #143 (comment)

Verify if this is the case and add a check to verify this, also see about simplifying the constructor as a result of this.

Resonance Parameter classes should provide LRU and LRF getters

Implement python helper function like from_file on the C++ side as well

See @nathangibson14's comment in PR #92

ENDFtk tests fail on tail verification since disco update

The disco library was recently updated to be more flexible in its parsing of integers and doubles (e.g. left aligned instead of right aligned, etc.). Since the update, most tests in ENDFtk appear to fail due to tail verification.

For example, the ListRecord constructor throws an exception when trying to read this ENDF snippet:

 1.001000+3 9.991673-1          0          0         10          5 125 1451     
 0.000000+0 1.000000+0 2.000000+0 3.000000+0 4.000000+0 5.000000+0 125 1451     
 6.000000+0 7.000000+0 8.000000+0 9.000000+0                       125 1451     

The information given in the test report is the following:
[error] The record section number (MT) is inconsistent with expectation.
[info] The read section number is: 14
[info] The expected section number is: 451
[info] Error encountered while verifying record tail values

The code apparently tries to read the " 14" instead of "451" as the MT number in the tail verification.

It should be noted that this appears to occur only when reading sequences over multiple lines, and then only when the last line does not contain 6 entries. In the above example, the last two entries of the last line are blank.

I think the issue might be in the readPartialLine() function of the Zipper component in ENDFtk. That is how far I got in trying to figure it out.

Add capability to construct a section::Type<N> from syntaxTree Section.

This makes life much easier by removing the requirement to write several lines of boilerplate code to get the section you want.

L2 parameter in CONT record in MF=3 is 99 for redundant reactions in PENDF file

While comparing legacy PENDF files to modern PENDF files, I discovered an undocumented (surprised?) "feature". Legacy NJOY sets the L2 parameter of the CONT record in MF=3 to 99 for redundant reactions. I suppose this is some sort of flag that states that this is a redundant reaction.

What is the right way to allow this in ENDFtk? I could write another constructor for MF=3 that has a flag that it is a redundant reaction, but I suspect the TabulationRecord doesn't have the appropriate constructor to match.

Problems with one of the constructors (copy?)

The following compiles, but gives a SIGABRT when run

struct make{
  using Tape_t = syntaxTree::Tape< std::string >;
  using Format_t = std::variant< Tape_t >;

  static
  Format_t makeTape(){
    std::string tapeString{/*something here*/};
    Tape_t tape{ std::move( tapeString ) };
    return tape;
    }
};

auto evaluated = make::makeTape();

I'm not sure, but I think there is something wrong with with one of the constructors.

The problem lies in creating the Tape_t object and then "converting" it to the Format_t (std::variant). An alternative implementation of makeTape, that doesn't cause a SIGABRT is:

static
Format_t makeTape(){
  std::string tapeString{/*something here*/};
  Format_t tape{ std::move( tapeString ) };
  return tape;
}

I think (but not sure) that this indicates a problem with the copy or move constructor.

Getters taking int should be renamed

We have a number of "getters" that don't feel a little awkward. For example:

decltype( auto ) material = tape.materialNumber( 125 );

This feels like the type of material would be an int (a material number). Similarly:

decltype( auto ) material = tape.materialNumber( 125 );
decltype( auto ) file = material.fileNumber ( 3 );
decltype( auto ) section = file.sectionNumber( 102 );

Because of the name of the method, it feels like these should return an int.

I propose that we should rename these functions and remove the Number at the end of each function name, such as:

decltype( auto ) material = tape.material( 125 );
decltype( auto ) file = material.file ( 3 );
decltype( auto ) section = file.section( 102 );

This makes it feel like the return type will be a Material, File, or Section respectively.

This is a relatively big API change. However, it is just a search/replace in the current repository. There is only one other component that currently uses ENDFtk (to my knowledge) so we should decide what is the best way to do this and do it right before it becomes too difficult to change it.

missing getters

file::Type<N> , file::Type<1>, and file::Type<2> does not provide a fileNumber getter. Delegating to the existing MF method should suffice.

Likewise with section::Type specializations have the analogous issue. Adding the method to the section::Base could avoid the duplication.

Issue when chaining commands

Using U235 from ENDF-B-VIII.0 (n-092_U_235.endf) with the njoy file below I notice some issues when trying to parse the output (tape50) in ENDFtk.

moder
20 -30
reconr
-30 -21 /
'reconstructed u235' /
9228 /
0.001 /
0 /
broadr
-30 -21 -22
9228 /
0.01 /
300 /
0 /
heatr
-30 -22 -23 0 /
9228 3 /
302 318 402 /
moder
-23 50
stop

It seems strange to me, although perhaps I have made a mistake :), that the following produces a seg fault.

import ENDFtk as tk
x = tk.tree.Tape.from_file('./tape50').materials.front().section(3,2).parse()

whereas doing this in the more verbose way as below, produces no error.

import ENDFtk as tk

tape = tk.tree.Tape.from_file('./tape50')
mat = tape.materials.front()
mf3_mt2 = mat.section(3, 2).parse()
print(mf3_mt2.energies.to_list())

Note my system is: python3.11 with ENDFtk compiled from source on Ubuntu 20.04 with gcc 9.4.0.

Am I misunderstanding the ENDFtk API or could this be a bug?

operator==() in EndfTk record implemetations should be const

The operator==() functions implemented for the list and tab1 are not const. These are the only ones that we actually looked at but the other ones should be checked as well (you never know).

Add convenience enumerators for ENDF options

For example:

• to easily identify resonance formalisms and types: ResonanceType.resolved and ResonanceType.unresolved

We can then write code like:

if resonances.LRU == Formalism.ReichMoore :

    print( 'found one' )

instead of:

if resonances.LRU == 3 :

    print( 'found one' )

Isotope test crashes with std::exception

The test at src/ENDFtk/resonanceParameters/Isotope/test/Isotope.test.cpp fails at line 196 (although I think it is at line 973

This test failed to compile (don't know why we didn't catch this before) and I had to remove ); already.

Make a shorter MF1 MT451 constructor

This would allow us to retrieve the parameters and description without having to re-enter them in the constructor when we only want to modify the directory.

FindPython3

I (unfortunately) have a machine with both python 2 and 3 installed. When building the python bindings using develop, cmake naturally finds the WRONG python. To resolve the issue, I add find_package(Python3 REQUIRED). CMake does report that it finds Python3 (the corresponding path looks right).

-- Found Python3: /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8 

It also reports that it is finding PythonInterp which points to the wrong python:

-- Found PythonInterp: /usr/bin/python (found version "2.7.16") 

so I also added find_package(PythonInterp 3). After adding the latter,

-- Could NOT find PythonInterp: Found unsuitable version "2.7.16", but required is at least "3" (found /usr/bin/python)

the above is a soft error because I did not add REQUIRED to find_package(PythonInterp 3). Here is what I added:

find_package(Python3 REQUIRED)
find_package(PythonInterp 3)

I don't know that the second line is absolutely necessary. I would recommend at least conditionally calling find_package(Python3 REQUIRED) such that it is a hard requirement if you want to build the python bindings (considering python3 is required).

TabulationRecord verification is too strict for duplicate x values

The ENDF format allows for duplicate x values in a TAB1 (and other places). There is a verifyXValuesAreSorted function called during the TabulationRecord (i.e., TAB1) constructor. It's a little too strict and doesn't allow adjacent, duplicate x values.

Lift common code in enumerated files to file::Base

Some code still needs to be lifted from file::Type<1>, file::Type<7> and file::Type<8> such as the print function.

TAB1 is not copyable

Add `NC` getter to section types.

This morning I discovered that the directory in 451 doesn't provide NS values but rather, a count of the number of records within each section (excluding the send) designated NC. A getter for this value would require no additional storage and would be helpful when generating the directory.

Move python wrapped view types to their own ENDFtk submodule

NT

Add insert, insert_or_replace, remove, etc. functions to tree.Tape

This would complete the ENDFtk tree with full insertion and removal on all levels of the tree (Tape, Material and File).

Allow for the use of elementary.ParticleID in ENDFtk

Elementary is an NJOY component that allows us to identify nuclides, nuclei, elements, etc. See here for more information: https://github.com/njoy/elementary

A development version has python bindings for this library.

One of the inconveniences with ENDFtk, is that we need to know the MAT number in order to extract a material from a tape (python pseudo code):

tape = ENDFtk.tree.Tape.from_file( 'some_file_for_U235.endf' )
material = tape.material( 9228 ).parse()

Being able to use an elementary ParticleID would be a big advantage:

u235 = elementary.ParticleID( 'U235_e0' )
tape = ENDFtk.tree.Tape.from_file( 'some_file_for_U235.endf' )
material = tape.material( u235 ).parse()

Using the elementary identifiers elsewhere in ENDFtk (e.g. to extract reaction products, fission yields, etc.) would be a large improvement as well.

TAB2 record needs to be implemented

TAB2 is required to finish implementing the file 1 sections (used in mt455).

int64_t or similar in ENDF records should be replaced with long

The HeadRecord uses long to store the L1, L2, N1 and N2 fields while the ListRecord and ContRecord uses int64_t.

To be coherent, these fields should be long everywhere.

I assume that the basic definition would then be: floating point values in double and integer values in long.

Compiling error when compiling tests

When building a new version of ENDFtk, compilation errors when trying to build a test. Disabling the tests allows the compilation to complete.

Commands Used:

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

Here is the terminal output:

...
[ 60%] Building CXX object src/ENDFtk/section/5/TabulatedSpectrum/OutgoingEnergyDistribution/test/CMakeFiles/ENDFtk.section.5.TabulatedSpectrum.OutgoingEnergyDistribution.test.dir/OutgoingEnergyDistribution.test.cpp.o
[ 60%] Built target ENDFtk.section.5.MadlandNixSpectrum.test
[ 60%] Building CXX object src/ENDFtk/section/5/TabulatedSpectrum/test/CMakeFiles/ENDFtk.section.5.TabulatedSpectrum.test.dir/TabulatedSpectrum.test.cpp.o
[ 60%] Linking CXX executable ENDFtk.section.5.MaxwellianFissionSpectrum.test
[ 60%] Built target ENDFtk.section.5.MaxwellianFissionSpectrum.test
[ 60%] Building CXX object src/ENDFtk/section/5/WattSpectrum/test/CMakeFiles/ENDFtk.section.5.WattSpectrum.test.dir/WattSpectrum.test.cpp.o
[ 61%] Linking CXX executable ENDFtk.section.5.Parameter.test
[ 61%] Built target ENDFtk.section.5.Parameter.test
[ 61%] Building CXX object src/ENDFtk/section/5/test/CMakeFiles/ENDFtk.section.5.test.dir/5.test.cpp.o
In file included from /usr/include/signal.h:328,
                 from /home/blakec4/SchoolPrograms/test_ENDFtk/ENDFtk/build/_deps/catch-adapter-src/src/single_include/catch.hpp:6520,
                 from /home/blakec4/SchoolPrograms/test_ENDFtk/ENDFtk/src/ENDFtk/section/5/WattSpectrum/test/WattSpectrum.test.cpp:3:
/home/blakec4/SchoolPrograms/test_ENDFtk/ENDFtk/build/_deps/catch-adapter-src/src/single_include/catch.hpp:6543:33: error: size of array ‘altStackMem’ is not an integral constant-expression
 6543 |         static char altStackMem[SIGSTKSZ];
      |                                 ^~~~~~~~
/home/blakec4/SchoolPrograms/test_ENDFtk/ENDFtk/build/_deps/catch-adapter-src/src/single_include/catch.hpp:6594:45: error: size of array ‘altStackMem’ is not an integral constant-expression
 6594 |     char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
      |                                             ^~~~~~~~
make[2]: *** [src/ENDFtk/section/5/WattSpectrum/test/CMakeFiles/ENDFtk.section.5.WattSpectrum.test.dir/build.make:76: src/ENDFtk/section/5/WattSpectrum/test/CMakeFiles/ENDFtk.section.5.WattSpectrum.test.dir/WattSpectrum.test.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:7712: src/ENDFtk/section/5/WattSpectrum/test/CMakeFiles/ENDFtk.section.5.WattSpectrum.test.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 61%] Linking CXX executable ENDFtk.section.5.Probability.test
[ 61%] Built target ENDFtk.section.5.Probability.test
[ 61%] Linking CXX executable ENDFtk.section.4.test
[ 61%] Built target ENDFtk.section.4.test
[ 61%] Linking CXX executable ENDFtk.section.5.TabulatedSpectrum.OutgoingEnergyDistribution.test
[ 61%] Built target ENDFtk.section.5.TabulatedSpectrum.OutgoingEnergyDistribution.test
[ 62%] Linking CXX executable ENDFtk.section.5.TabulatedSpectrum.test
[ 62%] Built target ENDFtk.section.5.TabulatedSpectrum.test
[ 62%] Linking CXX executable ENDFtk.section.5.PartialDistribution.test
[ 62%] Built target ENDFtk.section.5.PartialDistribution.test
[ 62%] Linking CXX executable ENDFtk.section.5.test
[ 62%] Built target ENDFtk.section.5.test
lto-wrapper: warning: using serial compilation of 128 LTRANS jobs
^Cmake[2]: *** Deleting file 'ENDFtk.cpython-311-x86_64-linux-gnu.so'
make[2]: *** [CMakeFiles/ENDFtk.python.dir/build.make:3794: ENDFtk.cpython-311-x86_64-linux-gnu.so] Interrupt
make[1]: *** [CMakeFiles/Makefile2:5172: CMakeFiles/ENDFtk.python.dir/all] Interrupt
make: *** [Makefile:146: all] Interrupt

Here is the full terminal output:

ENDFtk_build_error.txt

Add a to_file() method similar to to_string()

@ameliajo suggested adding a to_file() method similar to to_string() to write sections, files, etc. to files directly without having to use the to_string() function and dumping it into a file afterwards.

Because we already have a large amount of developments in #92, I'm making this an enhancement issue to be addressed later.

Comparison of integers of different signs

When compiling NJOY21, I get the following compilation error:

/Users/jlconlin/NJOY21/Code/NJOY21/bin-llvm/_deps/endftk-src/src/ENDFtk/section/1/455/DecayConstants/src/generateList.hpp:11:12: error: comparison of
      integers of different signs: 'int' and 'std::__1::vector<double, std::__1::allocator<double> >::size_type' (aka 'unsigned long')
      [-Werror,-Wsign-compare]
  if ( nnf != abundances.size() ) {
       ~~~ ^  ~~~~~~~~~~~~~~~~~
/Users/jlconlin/NJOY21/Code/NJOY21/bin-llvm/_deps/endftk-src/src/ENDFtk/section/1/455/DecayConstants/src/generateList.hpp:21:31: error: comparison of
      integers of different signs: 'unsigned int' and 'int' [-Werror,-Wsign-compare]
  for ( unsigned int i = 0; i < nnf; ++i ) {
                            ~ ^ ~~~

I'm not sure why this doesn't show up when compiling the tests.

Add a convenience function to get the first material in a TAPE

For example:

material = tape.mat()
material = tape.front()

As a side note: maybe add front(), back() functions to the view interfaces?

Deal with negative NP and NR values in TAB1/LIST Records

Add a function to create a tree::Tape from a file

In the C++ side of ENDFtk.

Compiling ENDFtk.python using g++-11 gives hana deprecation warnings

For example:

In file included from /Users/wim/Projects/njoy21/ENDFtk/build/_deps/hana-adapter-src/src/include/boost/hana.hpp:191,
                 from /Users/wim/Projects/njoy21/ENDFtk/src/ENDFtk/section/6.hpp:8,
                 from /Users/wim/Projects/njoy21/ENDFtk/python/src/section/6/DiscreteTwoBodyRecoils.python.cpp:6:
/Users/wim/Projects/njoy21/ENDFtk/build/_deps/hana-adapter-src/src/include/boost/hana/traits.hpp:71:62: warning: 'template<class _Tp> struct std::is_literal_type' is deprecated [-Wdeprecated-declarations]
   71 |     constexpr auto is_literal_type = detail::hana_trait<std::is_literal_type>{};

An update to remove the hana adapter and point to the latest hana release might be required.

Text record does not enforce 66 character limit

Desired behavior:
length > 66 characters -> throw
length < 66 characters -> right pad to 66 characters

Poor runtime_error message for invalid NXS in MF=1/MT=451

See line 15 of file section/1/451/src/readParameters.hpp (throw statement in code below).

if ( line2.N2() < 1 ){
    Log::error( "Number of index records (NXC) must be greater than or equal to one" );
    Log::info( "See line {}", lineNumber - 1 );
    throw std::runtime_error("Number of index records (NWD) must be greater than or equal to one");
  }

This should be NXC instead of NWD. It looks like a simple copy/paste error.

Reading Angular distributions

Dear Experts,
I am a newbie to ENDFtk and I am trying to extract the Angular distributions for certain incident energy from a JENDL-4.0 ENDF file.

I used the following command to get all incident energies that works well:

tape = ef.tree.Tape.from_file('natC.txt')
file2=mat.MF(4)
section2=file2.MT(2)
en2=section2.incident_energies.copy()

However, I used the following command to get the angular distributions:

angdis=section2.angular_distributions

but the output is :

<ENDFtk.sequence.any_view< variant< LegendreCoefficients&, TabulatedDistribution& >, random_access > object at 0x7f0f1d05fed8>

So, how can I access the LegendresCoeefficinets and TabulatedDistributions for an incident energy?

Any response is really appreciated.