njoy/leapr

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.

leapr's Issues

contin computing effective temperature is uncomfortable

Doesn't really seem to match the manual. Maybe the manual is wrong? It states that

teff ~ int b^2 P(b) exp(-b) db

when the code calls for fsum to use a tau of 0.5, meaning that the exponent in the calculated integral is -b/2. So this is strange, please look into

discre prepareParams not that great?

Consider maybe just getting rid of this, and evaluating things when they're used? This seems like a rather not straightforward approach, especially since ar vector and dbw vector only seem to be used like in one place

contin's handling of npn, npl, etc seems arwy

Becomes apparent when running H in ZrH case, that tnow --> tlast is not being invoked correctly. This may have implications on how you run convol, though, so be careful.

contin's interpolation checking out of bounds

This is a super small thing, but the interpolate.h function that contin uses only checks to see if the x value is larger than the vector, not smaller. This seems weird, so please look into whether this was done for a reason or not

discre's exts and prepareParams tests

You changed it to eliminate the unnecessary factor of two so you'll have to change tests as well

bfact in discre arbitrarily chooses loop end

bfact is used by discre to evaluate the A_in part of Eq. 537. The fun little sum in that eq. should be from -infty --> infty, but it only goes to 50. Change this later.

Change to discre's oscillatorLoop helper function makes it fail test case

line 48 of discre's oscLoopFuncs.h should be m < nn, not m <= nn I think. The former makes you fail oscLoopFuncs.test.cpp, but it appears to be necessary for getting leapr.cpp output to match. Probably something wrong with test case

coldh should be changed to use natural scalings of constants

right now coldh uses a value of hbar that is scaled by like 1e7, and same with elementary charge. Try and make the units more natural.

Write / get access to some way of writing to final file (endio)

Let's really hope that you don't have to write this, so maybe it exists somewhere else. If not, write it

trans spacing for beta grid, delta, seems arbitrary.

Located in the beginning of trans.h, please figure out why this definition was chosen.

coldHydrogen_util.betaLoop_util failed

I tried compiling/testing. It compiles fine, but one test fails:

1: /Users/jlconlin/NJOY21/Code/leapr/src/coldHydrogen/coldHydrogen_util/betaLoop_util/test/jprimeLoop.test.cpp:98: FAILED:
1:   REQUIRE( out == Approx(0.161404).epsilon(1e-6) )
1: with expansion:
1:   0.161370993 == Approx( 0.161404 )
1:
1: ===============================================================================
1: test cases:  2 |  1 passed | 1 failed
1: assertions: 12 | 11 passed | 1 failed
1:
1/1 Test #1: coldHydrogen.coldHydrogen_util.betaLoop_util ...***Failed    0.01 sec

trans is relatively slow

My trans, for simple water test case, takes about 0.05-0.06 seconds, while legacy trans is like 0.0002. So definitely see what might be causing that

if oscillator energy is too high (even like 205) their alternative implementation of tanh fails

When discre does its prepareParams, the legacy code writes out its hyperbolic functions explicitly, and calculates sinh(oscillator energy/2tev) and cosh(oscillator energy/2tev) separately, then uses that to calcualte tanh(oscillator energy/2tev). When oscillator energy is too big, this gets set to Inf, and the S(a,b) from discre gets set to all zeros.

My implementation just uses tanh(oscillator energy/2tev) directly, which doesn't go to infinity. yay! But should definitely make note that my code doesn't fail at the same point legacy code fails, so as to account for that during comparison

Note that if you replace the line
dbw(i)=ar(i)*cn
with
dbw(i)=adel(i)/(tanh(bdeln(i)/2)*bdeln(i))
then the legacy code won't fail. Also note that I'm encountering this problem when I use two oscillators, one of energy 205.0 and the other 0.48, and that it seems to occur with an oscillator energy of anywhere from 35-36.

coher fcc tests were written for when twopis and twothds were inputs

and they were not set equal to 2pi or to 2/3. So probably should rewrite those test cases. Oops

smin is not represented in the inputs.

try to add code to make the rest of card 4 seem welcome

Trans use of ndmax

in trans.h, ndmax is set equal to max(1e6,beta.size()). In s_table_generation, nds / nbt (goes by both names depending on which file we're in) is the number of S_t(a,b) values that were computed (determined by how quickly the S_t(a,bi) values get small).

According to s_table_generation, nds / nbt could be as big as ndmax. But when we inevitably go to sbfill.h, it throws an error if nds is greater than 0.5*ndmax. So that is already a problem that could be caught further upstream.

But what's more is that I don't particularly see why we need to define ndmax so early, could we just set ndmax equal to 2*nds? The only problem we'd have to work around is the fact that ndmax is used before we actually calculate nds, but we could mess with that a bit I think. Just want to avoid throwing an error to the user that could potentially be avoided. Also 1e6 is a lot of space that might not necessarily be necessary to reserve.

Coher's formf fucntion seems claims of #/positions of atoms per unit cell seem off

I've tried to look into this a good amount and haven't gotten anywhere, this would be a good thing to ask someone who knows structures better than I do.

coher bcc factor calculation

Line 2679-2680 of leapr.f90 redefines i1m to be two different things, which I'm not completely sure if that was a mistake or not. Strange. Try to figure out if i1m=15 is actually what we want or not. This behavior is in bccLatticeFactors.h for coher in c++ translation

discre's exb vector has useless factor of 2

exb, which is populated in discre_util/prepareParams.h, is equal to exp( -beta * sc / 2 ), but the only time that it seems to be used (when populating the sex vector) has exb squared. So that's weird, but that's okay. Maybe change that

coldh ifree capability

In order to take advantage of Eq. 569 and Eq. 570 (which assumes that the molecular transitions are free) you have to go in and manually change "ifree" to 1. This is not good

add tests in trans.test.cpp in for free gas case

Also try and figure out why 1e-4 is as accurate as we can get it

3 lines in oscLoopFuncs causing grief

Change these 3 lines and we pass oscLoopFuncs.test.cpp and discre.test.cpp. Leave them alone and we pass leapr.test.cpp

Do fix this, I can't even right now

enable leapr to handle multiple temps

coher hex function -- on the .ge. vs. .gt. situation

There's a location in hexagonal part of coher (I have it in hexLatticeFactors.h, or rather in hexLatticeFactorsHelper.h) where we check to see if tsq >= b[ifl+2*i-3]. The equals part of this is really messing with me.

Legacy code says that tsq and b[x] values of 1.5800000165571461E+018 and 1.5800000430651474E+018 (respectively) are different, so it doesn't go into the if conditional. Mine is treating them as the same.

Honestly probably the best thing to do is to just take the equality part of this out of the legacy code, see what answers it produces, check to make sure they're not too wildly crazy, and then design my code to match that.

change test cases for coher bcc to reflect no twopis input

Make adequate test cases for bccLatticeFactors

confusion regarding Eq. 531 for trans's s_table_generation

Line 49-51 in the amendments for s_diffusion vector, the specialized treatment for values for expTerm<= 1 vs > 1 seems a bit mysterious. Please check that out before too long

Change all those silly equal(double,double) functions to catch assertions

Now that you know that exists

trans's sbfill

Just some things to make it cleaner

don't take in sb, create it in sbfill and return it
don't take in ndmax, compute it
don't take in be, take b

and change the test cases and places it's used accordingly

checking moments part of contin is important

I didn't write it originally because I figured it wasn't important, but looks like it is indeed necessary, at least for H in ZrH test case.

Change s(a,b) to be eigen matrix instead of nested vector

Discre's sint's SCT approximation seems wrong

Beginning of the sint function, SCT approximation is considered, but doesn't match the happy Gaussian form that's shown in Eq.528. Do look into that

replace bessel function generating functions with built in ones

because apparently that's something I can do. At least check for the ones that have them written already, it should likely be faster than current methods

in the thermr branch piece, weird things happening with readWrite_util tests and iel_util tests

Currently a lot of things are commented out, something to do with the suspicious emotions that metaconfigure has about my code

coher wint is always equal to zero

Doesn't seem to ever change, might enable other options that aren't mentioned in the manual?

discre effective temperature calculation

discre may (?) be calculating effective temperature wrong? In the original source code it's line it's around line 1343 that dist(i) is defined to be

weight * ( beta / 2 ) * coth ( normalized_beta / 2 )

(this code is presently in my discre-->discre_util-->oscLoopFuncs.h)
But according to Eq. 544 I think this should rather be

weight * ( normalized_beta / 2 ) * coth ( normalized_beta / 2 ) or
weight * ( beta / 2 ) * coth ( beta / 2 )

meaning that legacy line 1343 should likely have bdeln(i) instead of bdel(i)

Worry that trans warps the beta grid

Trans changes the beta spacing, it defines a different delta in the beginning of trans.h. The existent S(a,b) that was generated in contin is then scaled to reflect this change, and the changed version of this S(a,b) is output from sbfill into the vector previously known as sb (I changed it to be sab). Then Eq. 535 is calculated and the result is put into the final sym_sab vector. This worries me, just because we're changing the beta grid halfway through the inelastic calculations. Please look into this, it might be nothing but just to be sure

contin/contin_util/checkMoments.h and sum0

Try to determine just how important sum0 is, and if we need to get it working. It's a bit of a pain to get sum0 and sum1 working with ranges, so I'm just going to push that until later once I figure out just how necessary it is.