NJOY 97.0 31 Oct 97 ----------------------------------------------------------------------- This is version 97.0 of the NJOY nuclear data processing system. It is a cleaned up version of NJOY 94.105 that features compatibility with a wider variety of compilers and machines, explicit double precisioning for 32-bit systems, a larger test-problem suite, a new revision control system, and some changes to the user input. To help the user, the following sections start with specific key phrases; use your editor to search for the desired topics. << The NJOY Nuclear Data Processing System >> << NJOY documentation >> << changes made between 94.105 and 97.0 >> << distribution files >> << installation on unix machines >> << installation on DOS/Windows machines using Lahey LF90 >> << revision control with upd >> << notes on machine dependencies >> << test problems >> This version has been tested on a Cray YMP with both static and stack-based memory allocation with a Fortran-90 compiler, on a Sun Ultra in 32-bit mode using f90, on a Sun Ultra in 64-bit mode (-dbl) using f77, on a Pentium 90 using linux g77 (32 bits with stack-based memory allocation), on an IBM RS/6000 using f77 (with f90 libraries available), on a DEC Alpha under f90, and on NT and Win95 using the DOS-based Lahey LF90 compiler. Supporting files for other systems will have to be updated from the NJOY94 versions by analogy with the NJOY97 versions. Users not supported by the files in this distribution are requested to send back the appropriate patches for their machines for further distribution. ----------------------------------------------------------------------- << The NJOY Nuclear Data Processing System >> The NJOY Nuclear Data Processing System is a modular computer code used for converting evaluated nuclear data in the ENDF format into libraries useful for applications calculations. Because the Evaluated Nuclear Data File (ENDF) format is used all around the world (e.g., ENDF/B-VI in the US, JEF-2.2 in Europe, JENDL-3.2 in Japan, BROND-2.2 in Russia), NJOY gives its users access to a wide variety of the most up-to-date nuclear data. NJOY provides comprehensive capabilities for processing evaluated data, and it can serve applications ranging from continuous-energy Monte Carlo (MCNP), through deterministic transport codes (DANT, ANISN, DORT), to reactor lattice codes (WIMS, EPRI). The modular nature of NJOY makes it easier to add output for other kinds of application libraries or to add new computational features. NJOY handles a wide variety of nuclear effects, including resonances, Doppler broadening, heating (KERMA), radiation damage, thermal scattering (even cold moderators), gas production, neutrons and charged particles, photoatomic interactions, self shielding, probability tables, photon production, and high-energy interactions (to 150 MeV). Output can include printed listings, special library files for applications, and Postscript graphics (plus color). ----------------------------------------------------------------------- << NJOY documentation >> New documentation for NJOY97 is not yet available. In the meantime, use the NJOY91 documentation in the report "The NJOY Nuclear Data Processing System, Version 91," LA-12740-M (1994). The differences in user input will be found in the Userinp file that comes with the distribution, or in the comments in the source code. For more information on LEAPR, see "New Thermal Neutron Scattering Files for ENDF/B-VI Release 2," LA-12639-MS (1994). The reports are available by request or in Postscript form in the Publications area of http://t2.lanl.gov/. ----------------------------------------------------------------------- << changes made between 94.105 and 97.0 >> We started with NJOY 94.105 as given in the Codes area on the t2 web site (http://t2.lanl.gov) and made a new src file using upd. We then went through the code and removed all Hollerith literals and most uses of Hollerith variables. The Lahey Fortran-90 compiler won't accept Hollerith literals at all. Removing them also will make future upgrades to stricter interpretations of Fortran-90 easier. We removed all format statements and replaced them with inline format strings in the read and write statements. This was closely coordinated with the removal of Hollerith literals--no more nH specifications! Some of the stricter dialects of Fortran-90 don't allow format statements, and the inline format strings make browsing through the code a little easier. We retired the infree subroutine after long and distinguished service. It made too much use of Hollerith variables. We now use the standard READ* list-directed input routine. Unfortunately, this means that input decks will have to be changed to use quotes as the string delimiters instead of stars. We abandoned the interactive input mode for NJOY. The prompting for READ* was not as good as with infree. Except for the shortest kinds of runs, the wait for each module to finish running before entering the input lines for the next module was inconvenient. A free standing input preparation routine based on prototypes, or an input GUI will probably take the place of the old interactive mode in the near future. We provide three different ways to get 64-bit arithmetic capabilities: native (as on the Cray), auto doubling (as with -dbl or -r8 flags on some compilers), or by explicitly including REAL*8 statements. The "set sw" option of upd controls whether explicit double-precision statements get compiled in. The introduction of explicit double precisioning required taking extra care with some other coding practices. You have to be careful to never use a real constant as a parameter in a function or subroutine call (NJOY often used "call routine(0.,..." to cause routine to initialize itself; we had to change all such constructions to things like "e=0; call routine(e,..."). You have to be careful to never use real constants in comparisons (except "if (x.eq.0.) ..." seems to work OK). You have to avoid using real "literals" in expressions. For example, in ACER we often converted from eV to MeV using things like "e*1.e-6"; these all had to be replaced with "e*tomev". The factor "tomev" has to be set in one of two data statements controlled by the "set sw" flag so that it is 1.e-6 on 64-bit machines and 1.d-6 on 32-bit machines. All constants with real physical meaning , such as pi or hbar, were moved into dual data statements controlled by "*if sw". In many places, simple constants like .25 or .5 had to be put into dual data statements with names like "quart" or "half" to get good results using both 64-bit and 32-bit machines. A number of common statements were restructured to fix potential word-alignment problems on machines where 8-byte reals and 4-byte integers coexist. Because many 32-bit machines cannot handle 8-byte integers, we were forced to use real*4 variables for the CCCC-type files (CCCCR, MATCSR, RESXSR) on 32-bit machines, which have records containing a mix of real, integer, and Hollerith data. We reworked the logic used for generating energy grids in RECONR and BROADR to make the results less machine dependent. The new logic tries to get 7 significant figures when possible, and goes on to use 9 significant figures if neccesary (but only for resonance energies). In order to do this, the ENDF I/O routines are modified to use both the normal 11-character format (e.g., +1.234567+2) or the extended form +123.456789. The later form is only used for energies between 1 eV and 1 MeV. In practice, the 9-digit form appears only rarely, and usually only at zero temperature, but the full accuracy is available for Doppler broadening or for comparisons with other codes. Thus, most ENDF-style ASCII files look pretty much like they always have. The NJOY binary files now use 64-bit accuracy on all machines. As a result of these changes, it is now possible to compare PENDF or ACE files generated on different machines using simple tools like diff. The energy grids will usually be identical, and the dependent cross sections will only differ occasionally. We took some care to make sure that SAVE statements were included where necessary, and we tested the code on compilers that need the SAVE statements (stack-based memory allocation) and compilers that do not (static memory allocation). We also added EXTERNAL statements for all the routines that call other routines. This is necessary for Fortran-90 compilers because the increased number of intrinsics leads to naming conflicts with NJOY routines. The code now determines the particular version of the ENDF format being used automatically, and the iverf parameter has been removed from the user input. Some of the very long subroutines were broken up into several parts to allow compiling to take place on machines with limited memory. Old-fashioned Fortran constructs were changed to use newer styles in a few places when it was convenient. Some f90 compilers complain that ending a DO loop on any statement except CONTINUE or ENDDO is obsolescent; therefore, we have removed all such cases from NJOY. The two goals of all of this work were (1) to move part way to Fortran-90 style without giving up F77 compatibility, and (2) to get the same results from NJOY runs made on many different machines. We didn't quite achieve the latter--but we will continue trying! ----------------------------------------------------------------------- << distribution files >> The distribution files for the unix version of NJOY 97 are as follows: Readme0 this information file Userinp text file of NJOY input instructions src upd source file (contains *deck cards) up0 upd directives input file for 97.0 upsun specialized updates for Sun workstations upsun8 specialized updates for Sun using -dbl option upcray specialized updates for UNICOS at Los Alamos uprs6k specialized updates for IBM RS/6000 machines updecau specialized updates for DEC Alpha unix uplinux specialized updates for linux using g77 makef.sun Sun make file for maintaining njoy makef.sun8 Sun make file for for -dbl option (see upsun8) makef.cray UNICOS make file for maintaining njoy makef.rs6k IBM RS/6000 make file for maintaining njoy makef.decau DEC Alpha unix make file for f90 makef.linux make file for linux using the g77 compiler in01 unix shell script to run test problem 1 out01 test problem 1 output from Sun Ultra 170 pend01 test problem 1 PENDF from Sun Ultra 170 in02 . out02 . pend02 . in03 . out03 . plot03.ps . in04 . out04 . in05 . out05 . plot05.ps . in06 . plot06.ps . in07 . out07 . pend07 . ace07 . in08 . out08 . pend08 . ace08 . in09 . out09 . pend09 . in10 . out10 . pend10 . ace10 . in11 . out11 . wims11 . in12 . out12 . plot12.ps . gam23 input data for test problem gam27 input data for test problem t322 input data for test problem t404 input data for test problem t511 input data for test problem eni61 input data for test problem upd.f version-control code for updating njoy (this version writes module.f) The distribution files for the DOS/Windows version of NJOY97 are: Readme0 this information file Userinp text file of NJOY input instructions src upd source file (contains *deck cards) up0 upd directives input file for 97.0 uplf90 specialized updates for Lahey LF90 lf90.fig options file to set exe name and bind in extensions njoy.exe executable for njoy upd.exe executable for upd test01.bat dos batch file to run test problem 1 in01.dat dos input file for test problem 1 out01 test problem 1 output from Pentium Pro 200 pend01 test problem 1 PENDF from Pentium Pro 200 test02.bat . in02.dat . out02 . pend02 . test03.bat . in03.dat . out03 . plot03.ps . test04.bat . in04.dat . out04 . test05.bat . in05.dat . out05 . plot05.ps . test06.bat . in06.dat . plot06.ps . test07.bat . in07.dat . out07 . pend07 . ace07 . test08.bat . in08.dat . out08 . pend08 . ace08 . test09.bat . in09.dat . out09 . pend09 . test10.bat . in10.dat . out10 . pend10 . ace10 . test11.bat . in11.dat . out11 . wims11 . test12.bat . in12.dat . out12 . plot12.ps . gam23 input data for test problem gam27 input data for test problem t322 input data for test problem t404 input data for test problem t511 input data for test problem eni61 input data for test problem upd.for version-control code for updating njoy (this version writes module.for) ----------------------------------------------------------------------- << installation on unix machines >> For the initial installation... Make sure the following files are in your working directory: makef.xxx for your system upd.f src up0 upxxx for your system and do the following: cp makef.xxx Makefile f90 -o upd upd.f (or cf90, f77, g77, ...) cat up0 upxxx > upn (check upn to make sure that "*set sw" is present, if needed) upd make xnjoy is your executable file module.f is a fortran compiler input file module.o is an object deck To make a change to NJOY 97.0 on unix ... Make sure the following files are available: upd (the executable version) upn (the expanded version) src Makefile module.f files module.o files previous xnjoy Edit upn to add the new upd "ident" and to list which modules need to be updated; for example, *cpl groupr *ident fixbug */ fix a hypothetical bug in groupr *d groupr.444,445 *ident vers ... Then just do the following: upd make Versions of the test problem input files in unix script form are included in the distribution of NJOY 97.0. To run the test problems, move the input scripts to a test directory created in the directory that contains the xnjoy file, and then simple type sh in01 and so on. Compare the resulting files, such as out01 and pend01, to the ones included in the distribution; e.g., diff out01 ../out01 > difs-out1 ----------------------------------------------------------------------- << installation on DOS/Windows machines using Lahey LF90 >> For the initial installation... Open the Lahey ED window and change the active directory to the NJOY97 working directory. Make sure that your working directory for NJOY97 contains the following files: src up0 uplf90 upd.for lf90.fig Open a DOS window. Edit lf90.fig to increase the level of optimization, turn off the binding in of the DOS extender, or whatever. (combine up0 and uplf90 into upn) copy up0+uplf90 upn (make sure that upn contains "*cmp all" and "*set sw") (compile upd) lf90 upd.for -out upd.exe (IMPORTANT: change the name of upd.for to upd.save to hide it from the automake process) ren upd.for upd.save (make the module.for files) upd Close the DOS window. Start the automake process. You will see it scan through the *.for files and then start the compilation process. There will be a large number of warnings about checking real numbers for equality, and a few other minor warnings. The final executable code will be njoy.exe. To run the test problems ... Create a subdirectory in your NJOY working directory called test. Move the in*.dat and test*.bat files into test. Make sure the following data files are available in your working directory (that is, the directory that contains test): t322 t404 t511 eni61 gam23 gam27 Using a DOS window, cd into test, and type "test01". Continue for test02, test03, etc. The result files, such as out01, out02, etc., will appear in the test directory. Compare the result files in the test directory with the one from the original distribution. To make changes to NJOY97 in the Lahey LF90 environment ... Edit upn to add the new upd "ident" and to list which modules need to be updated; for example, *cpl groupr *ident fixbug */ fix a hypothetical bug in groupr *d groupr.444,445 *ident vers ... Run upd from a DOS window. Then just press the automake button. ----------------------------------------------------------------------- << version control with upd >> Early versions of NJOY were maintained with CDC or Cray UPDATE, or with the UPEML update emulator from Sandia National Laboratory. This approach had the problems that not everybody had UPDATE and that UPEML wasn't exactly compatible with UPDATE for changes made upon earlier changes. For these reasons, NJOY was provided with its own version control program called UPD. This program performs the same functions as UPDATE, but it is very simple in order to make it easier to transport the code to a variety of computer systems. UPD has evolved slightly from version to version of NJOY, and the version for NJOY 97 works a little differently than the preceeding version. The original text of NJOY 97 is given in a file called "src", which contains "*deck module" cards at the start of each NJOY module (njoy, reconr, etc.). No binary program library is used. UPD directives are given in the file "upn". Each set of directives starts with the statement "*ident name" and contains additional statements like "*i address" or "*d address" followed by the text to be inserted or deleted. The UPD addresses can have forms like the following: reconr.151 groupr.522,533 matxsr.111,up20.33 The NJOY Quality Assurance program requires that idents be added to the upn file in strict sequence. The first card after each "*ident name" card must be a comment card giving the module, date, and purpose for the the change in the form */ groupr -- 30 Mar 95 -- fix problem with c.p. elastic */ reported by NEA-DB An ident should contain changes for only one module. Once an ident has been finished, dated, and released, it should never be changed directly. It should only be changed by some subsequent ident using line numbers like "up20.33". The conventional name for "official" idents are "up1", "up2", "up3", and so on. The corresponding version names would be "94.1", "94.2", "94.3", and so on. The last ident in upn is always "*ident vers", which has the following form: *ident vers */ update the version name and date */ to reflect the date of the latest modifications *d njoy.8,9 c * version 97.0 * c * 31 Oct 97 * *d njoy.279 data vers/'97.0 '/ This ident is changed as each ident is added to reflect the current version number and date. The result of this procedure is that it is always possible to determine what version was used to run a particular problem, and knowing the version, it it possible to determine the exact configuration of the code for any run. Code changes for different computer systems are handled by UPD in two ways. Generic changes are handled by "*if" constructs in the source file. Currently, two such options are implemented. Add the card "*set sw" at the start of upn for "short-word" machines (32-bit words). Add the card "*set wordio" to enable word-addressable I/O on UNICOS Crays. More specific system changes are included in a machine ident that must be copied onto the end of the upn file. Examples are given in the distribution (see upsun, upuni-la, upuni-sd, etc.). These updates normally do things like change the names of the local time and date routines and personalize the NJOY "banner" for the specific laboratory. It is usually easy to transport UPD between different computer systems. Unit 6 is intended for writing on the screen or an equivalent log file. This is the default for many systems. UPD can put out two different kinds of files, a conventional compiler input file "module.f", and a special listing file "module.lst". Beginning with UPD for NJOY 97, the code can write out several updated modules during one pass for more efficiency. For example, "*cpl reconr,broadr" would write out compile files for the two modules RECONR and BROADR. Then a simple "make" would recompile these two new decks and relink them into the NJOY executable. Similarly, "*lst groupr" would make a new listing file for GROUPR. For new installations, "*cpl all" and "*lst all" will make all the compile and listing files. Just typing "make" will then finish the entire installation. ---------------------------------------------------------------------- << notes on machine dependencies >> We have tried to keep all routines that depend on the particular machine, operating system, or compiler being used in the NJOY module. We have provided "upxxx" files and special "makef.xxx" files that will incorporate machine dependencies into NJOY for system that we are able to test ourselves. Other files have sometimes been contributed by users with access to other systems. If you have to bring the code up on a new system, these existing files may help to guide you. One of the machine dependencies that has always been around is the differences in time and date calls on different system. With the advent of Fortran-90, this has been partly alleviated. However, Fortran-90 doesn't have an intrinsic routine to return the amount of system time that has been used by a job. Some of our upxxx files just return a run time based on the system clock, which would not be accurate in a multi-processing environment. The LANL Cray system provides the "second" call, which works fine. You'll just have to try to provide the best option available on your own local system. Starting late the the NJOY94 series, we changed over to using the SLATEC libraries for fundamental math routines, because they are very accurate, and they can be used without restrictions. These routines require some basic parameters to describe the real number system used by your computer. The source code gives some options for mostly obsolete systems. Most modern machines use IEEE arithmetic, and one of the sets of constants included in our upxxx file should be OK. However, you would be well advised to check your system's documentation to more specific values for these parameters. Note that different sets of parameters are used on 32-bit (real*8) systems and 64-bit systems (like the Cray). There are still some problems with number systems and word length on the machines in wide use today. Classical 32-bit machines work fairly well in NJOY97 using real*8 variables. As a rule, these machines and compilers do not support integer*8 variables. This can create word-alignment problems, and we have tried to fix them. However, some cases require binary records with mixed real and binary elements (CCCC-type files). In these cases, we have had to limit ourselves to 32-bit accuracy using real*4 and integer*4 values. In some cases, the compilers have "-r8", "-i8", or "-dbl" options that automatically promote code written to 64-bit standards to run on 32-bit machines. This seems to work OK for NJOY on some systems. However, you have to be sure that the set of compiler options that you use promotes both reals and integers to 64-bit size in order to prevent word-alignment problems. Unfortunately, neigher linux g77 nor Sun f90 support such an autodoubling option, which is one of the reasons that we provided explicit doubling in NJOY97. The new generation of machines with 64-bit chips, such as the Sun Ultra, promise to eliminate this problem. However, the current compilers are not always completely 64-bit capable, and their abilities to use mixed real*8 and integer*8 data may be limited. Therefore, we are currently treating them just like 32-bit systems. Cray machines have always used 64-bit variables for both reals and integers, and there are no problems with mixed data. However, note that Cray arithmetic uses more bits in the exponents or real numbers and fewer in the fraction part. Therefore, numbers on the Cray have slightly less precision than those on the IEEE-type machines. ---------------------------------------------------------------------- << test problems >> An extensive set of test problems is provided with NJOY97, both to check an installation, and to provide examples of how to use NJOY. In order to provide continuity to earlier versions, we still use fairly old ENDF/B-III, -IV, and -V files for these tests. They also tend to have less detail than the new ENDF/B-VI files, which make the test problems run faster. Simple unix scripts or DOS batch files make it fairly easy to run the test problems. Problem 1: This one runs on carbon to check RECONR for materials with no resonance parameters, to do Doppler broadening to 300K, to calculate heating KERMA and radiation damage, and to calculate the thermal scattering from graphite. The pointwise (PENDF) results are converted into multigroup form. The important things to look at are the various counts in RECONR and the multigroup values from GROUPR on the file "out01". To see even more detail, check the PENDF file "pend01". Problem 2: This is a demonstration of preparing a library for LMFBR applications using methods active in the 80's. It is still useful for check RECONR resonance reconstruction, Doppler broadening to more than one temperature, the generation of unresolved resonance data, and multigroup averaging with self shielding. The CCCC output provides an alternative look at the cross sections and group-to-group matrices. Pay attention to the output from RECONR to see if the same number of resonance points are produced. Note the number of points at each temperature and the thermal quantities printed by BROADR. The unresolved self shielding shows up in the UNRESR output and again in GROUPR and CCCCR. The multigroup contants printed on "out02" provide plenty of opportunities to check your installation. For even more detail, check the PENDF file on "pend02". Problem 3: This one demonstrates processing photoatomic data and the use of MATXS output files. Newer versions of the photoatomic data are all on one file, rather than the two shown here. Note that two materials are processed to show the limiting behaviors. The multigroup constants printed by GAMINR on "out03" can be checked. Two different output formats are generated: the DTF format and the MATXS format. The DTFR numbers are given on the listing, and you can check the details of the MATXS results on "matxs03". DTFR also generates Postscript plots of its results; you can view them from "plot03" using ghostview or any Postscript printer. Problem 4: This test problem computes cross section covariances using the ERRORR module for U-235 from ENDF/B-V. The performance of ERRORR can be tested by looking at the values on "out04". Problem 5: This one demonstrates formating covariance data using our "boxer" format, and it generates detailed Postscript plots (in color) of the variances and correlations. Look at "plot05" with ghostview or a color Postscript printer. Problem 6: This case demonstrates and tests some of the features of the PLOTR and VIEWR modules. The output file is not very interesting, and we don't provide it. Look at "plot06" using ghostview or a Postscript printer. Problem 7: This example demonstrates the production of a library for the MCNP continuous-energy Monte Carlo code for Pu-238 from ENDF/B-IV. Older versions of MCNP required a set of multigroup photon production tables to construct the 30x20 grid of photon emission bins used in those days. This problem demonstrates how that was done, but the method is rarely needed these days. Still, these results provide another useful set of tests for your installation. The most interesting numbers are those in the ACER output on "out07". It is difficult to use tools like "diff" to compare such outputs unless the energy grids are exactly the same. Some of the changes made to NJOY97 were designed to try to achieve identical energy grids between different machines, and diff may work for you. If not, you can still spot check the results. We provide both the PENDF on "pend07" and the ACE file on "ace07" to allow for very detailed checks. Problem 8: This case was added to check the processing of a typical ENDF/B-VI material using Reich-Moore resonances and File 6 for energy-angle distributions. Pay special attention to the resonance results as shown by the counts on the RECONR listing and the values on the PENDF and ACE files (pend08 and ace08). In addition, check the energy-angle distributions as printed out by ACER on "out08". Problem 9: This one is new for NJOY97, and it demonstrates the use of LEAPR to generate a scattering kernel for water. We have used the ENDF physics model, but we reduced the alpha and beta ranges to make the case run faster with less output. Note that RECONR and BROADR are run to prepare a base for the thermal data at 296K. THERMR was run with its long printout option to provide plenty of numbers on "out09" for comparisions. For additional details, look at the the actual LEAPR output on "pend09". Problem 10: This one is also new for NJOY97, and it demonstrates the production of unresolved resonance probability tables for MCNP. We run both UNRESR and PURR using the same sigma0 grid to allow additional checks of both modules and to allow for comparisons between the deterministic and probabalistic approaches to computing Bondarenko cross sections. We provide the output listing on "out10", the PENDF file on "pend10", and the ACE file on "ace10". Lots of results to check. Problem 11: New for NJOY97. This one demonstrates the production of a library for the WIMS reactor lattice code using Pu-238 from ENDF/B-IV. Check both GROUPR output and WIMSR output on "out11". The WIMS library file produced is provided on "wims11". Problem 12: Also new. This one shows how the new gas production capability works with Ni-61 from ENDF/B-VI. To see the detailed results for gas production, look for MT=203 and 207 in File 3 of the PENDF tape "pend12". Also, check out the color Postscript plots of resonance cross sections and gas production cross sections on "plot12". Some interesting timing numbers for the test problems: test Cray YMP Sun Ultra Pentium Pro Pentium no (busy) 167 MHz 200 MHz 90 MHz f90 -fast g77 -O2 LF90 ------------------------------------------------------------ 01 499.9 71.8 55.0 158.1 02 310.1 56.9 49.6 136.7 03 99.3 19.4 20.4 04 23.7 8.6 6.2 22.9 05 331.1 136.3 59.1 355.8 06 4.0 11.0 07 193.8 40.4 34.8 108.4 08 305.4 73.3 56.2 246.2 09 296.2 44.6 58.1 95.5 10 390.1 50.8 56.2 114.4 11 736.4 112.8 93.5 241.4 12 62.6 15.0 15.8 41.1 ------------------------------------------------------------ These timings shouldn't be taken too seriously. For example, DOS seems to spend about 30 or 40 seconds churning before the clock printed out even starts.