Managing and Processing Nuclear Data Libraries with FUDGE

. FUDGE (For Updating Data and Generating Evaluations) is an open-source code that supports reading, visualizing, checking, modifying, and processing nuclear reaction and decay data. For ease of use the front-end of FUDGE is written in Python while C and C ++ routines are employed for computationally intensive calculations. FUDGE has been developed primarily at


Introduction
FUDGE was developed at LLNL as a tool to simplify accessing, visualizing, updating and processing nuclear data libraries [1]. The code was originally written to support data libraries in the LLNL-specific ENDL format [2], but it has since been updated to primarily support GNDS, the new international standard for storing both evaluated and processed data. While the code has gone through extensive changes during this process, the main goal remains the same: to provide a useful framework for managing nuclear data libraries that can be used interactively and that can serve as the foundation for building additional user scripts to automate tasks related to developing and maintaining nuclear data libraries.
FUDGE is an open-source code (released under the BSD 3-clause license) and is available for download at https://github.com/llnl/fudge. The latest release is v6.0, published in September 2022. For basic installation and use, the code depends only on Python (version 3.6 or later), numpy (version 1.15 or later), and a recent C / C++ compiler. Additional Python modules such as matplotlib, PyQT5, scipy and h5py may also be required for more advanced usage.
FUDGE can be installed in two ways: • Using the 'pip' Python package manager to install either in the system Python or in a virtual environment. • Cloning the repository, compiling using the included Makefile, and adding FUDGE to the PYTHONPATH.
More details about both installation methods are provided on the project page on github.
⇤ e-mail: mattoon1@llnl.gov Many of the Python modules in FUDGE define classes that mirror the GNDS hierarchy as spelled out in the GNDS specifications documents ( [3], [4]). These include classes such as the ReactionSuite, CovarianceSuite, Map and PoPs Database that each correspond to one of the main top-level GNDS nodes. At a minimum each class contains logic for converting itself to and from XML, for traversing up or down the GNDS hierarchy (i.e., for accessing child nodes and parent node), and for converting itself to an 'xpath', a string similar to a unix path that uniquely identifies the node within the GNDS structure. Most classes define additional methods to support visualizing, checking, modifying, and processing data.
FUDGE comes with several executable scripts to handle common tasks. These include: • buildMapFile.py, for generating a 'map' file that assembles multiple GNDS 'reactionSuite' files into a library (similar to the xsdir file used by MCNP), • checkMap.py, for checking 'map' files generated by buildMapFile, • checkGNDS.py, for performing physics checks on a GNDS evaluations and writing out a report of problems encountered in the file, • energySpectrum.py, for extracting and optionally plotting the outgoing energy spectrum for a given product at a given projectile energy, • di↵GNDS.py and patchGNDS.py, tools to summarize di↵erences between two GNDS evaluations and merge them into a new evaluation where needed, and • processProtare.py, the main driver for processing nuclear data libraries. processProtare is described in more detail in the next section.
When FUDGE is installed using pip, these executable scripts (along with many others) are copied into the environment 'bin' directory. If installed in a virtual environment, they will be available when that virtual environment is activated. Each script includes a '-h' or 'help' command-line option that prints detailed information about how the script can be used.
These scripts are designed to take GNDS files as input. To help users get started, FUDGE also comes with utilities for translating ENDF-6 data to and from GNDS. This converts GNDS data (including covariances if available) back to ENDF-6. Some ENDF-6 evaluations (including in major evaluated libraries) cannot yet be translated into GNDS, usually because they do not strictly adhere to the ENDF-6 format [5] or have internal inconsistencies. The endf2gnds.py script includes a '-verbose' command-line option that can be useful for understanding the source of errors that show up during translation to GNDS, and also includes options like '-skipBadData' and '-skipCovariances' that can be used to obtain a partial GNDS translation if some parts of the original ENDF file could not be translated due to format errors or other problems. FUDGE v6.0 generates GNDS-2.0 files by default. However, FUDGE still supports reading and writing files in the GNDS-1.10 format.

Processing with FUDGE
The 'processProtare.py' script is the primary tool in FUDGE for processing nuclear reaction data for use in Monte Carlo and deterministic transport codes. The script takes a GNDS 'reactionSuite' file as input, processes it according to user-supplied options, and generates another GNDS file containing the final processed data. If the data were processed to multiple temperatures, the resulting file will contain several di↵erent 'styles' of data corresponding to the di↵erent temperatures and processing options.
processProtare.py goes through several steps: 1. Converting parameterized forms into cross sections and potentially outgoing product distributions. The most common example is reconstructing cross sections from resonance parameters, but other examples include processing thermal neutron scattering law (TNSL) data where the original evaluation stores parameterized terms such as the Debye-Waller integral for incoherent elastic scattering and S(↵, ) for incoherent inelastic scattering, and processing photo-atomic interactions where the original evaluation stores form and anomalous scattering factors for coherent and scattering functinos for and incoherent photon scattering. In some cases it may be possible for Monte Carlo codes to sample directly from the parameterized forms, but FUDGE still must convert these terms to cross sections and distributions in order to compute average product energies / multiplicities and to generate multi-group data.
2. Integrating distribution data to compute average outgoing product energy and momentum. These averages are used during radiation transport simulations to keep track of energy deposition and heating in the material.
3. (for Monte-Carlo processing only): pre-computing cumulative probability densities for all outgoing distributions. Both the probability distribution function (pdf) and cumulative distribution function (cdf) are needed when sampling from the distribution.
4. Doppler-broadening cross sections to account for material temperature. FUDGE uses the kernel broadening method, and broadens at all incident energies. Doppler broadening cross sections below threshold is supported but is not typically used since the corresponding distribution data do not extend below threshold and cannot be easily broadened.
5. (for Monte-Carlo processing only): putting all reaction cross sections onto a union energy grid at each temperature, to speed up cross section lookup during sampling.
6. (for multi-group processing only): generating grouped, flux-weighted cross sections, average available energy, outgoing product multiplicities and average product energy / momentum for each temperature. The flux and particle-specific group boundaries are determined by command-line options.
7. (for multi-group processing only): generating temperature-dependent transfer matrices and thermal upscatter corrections for elastic scattering. Generating transfer matrices requires expensive multidimensional integrals, so for faster processing this step is performed by the C++ code Merced [6] (written by G. Hedstrom) which supports a wide variety of product distributions and frames.

processProtare input files
Due to the many ways that nuclear data can be processed, processProtare.py has many di↵erent command-line options. To simplify processing, these options can be read from standard input files rather than being supplied each time on the command line. For example, a simple processing command is processProtare.py eval.xml -o processed.xml \ @processingArguments This processes the GNDS file 'eval.xml' according to the arguments in the file 'processingArguments' and writes the result to the GNDS file 'processed.xml'. 'processingArguments' may contain a wide range of command-line options including what type of processing to perform (Monte Carlo and/or multi-group), the choice of flux and group boundaries, a list of temperatures, and so on. A full list of processing options is available by running processProtare.py with the '-help' option.
A simple processingArguments file might simply consist of a short list of temperatures and the flag to enable Monte Carlo processing: --energyUnit eV --temperatureUnit K -mc -t 293.6 -t 450 -t 600 A more complicated processing setup might include multi-group processing with di↵erent group boundaries for neutrons and photons: This style of input is meant to simplify the task of processing an entire library with consistent options, without having to tailor input files for each reactionSuite in the library. If processProtare determines that a processing step does not apply to the current target (e.g., resonance reconstruction for a reactionSuite with no resonance parameters), it simply skips that step and moves on to the next processing step. FUDGE and processProtare.py have already been used to process and deploy multiple data libraries at LLNL, including LLNL's own ENDL2009 and ENDL2011 as well as ENDF-VII.1, ENDF-VIII.0 and several recent versions of TENDL. Processed results have been compared against other processing codes including NJOY [7], AMPX [8], PREPRO [9] and FRENDY [10] as well as against legacy LLNL processing codes.
After processing, GNDS data files can be read and sampled using the GIDI+ library, a C++ API also developed by by the Nuclear Data and Theory group at LLNL [11]. Like FUDGE, GIDI+ is an open-source code that is available from https://github.com/llnl/gidiplus. It has been integrated into several LLNL transport codes including the Monte Carlo code Mercury [12] and the deterministic code ARDRA [13]. An older version of GIDI+ is available in GEANT-4 [14] via the G4LEND package, and an e↵ort is currently underway to update G4LEND to the latest version of GIDI+.
Users are also taking advantage of the flexibility of GNDS 'map' files to customize nuclear data libraries. Since one map file can import another, users are able to easily build hybrid libraries. For example, a map file can specify to use LLNL's ENDL2009.4, but replace some isotopes with the latest from ENDF-VIII.0, or to use ENDF/B-VIII.0, but fill in any missing isotopes using TENDL2019. The 'buildMapFile.py' script mentioned above helps with generating such hybrid map files.

Recent developments and future work
Recent developments in FUDGE include: • updates to fully support reading and writing GNDS-2.0 (while maintaining backwards-compatibility with previous version GNDS-1.10). • improvements to processing of thermal neutron scattering law (TNSL) data to improve both processing throughput and the fidelity of results. Example results are seen in figure 1. • support for writing out 'hybrid' files, where the GNDS hierarchy is stored in XML while large datasets are stored in HDF5 arrays. These hybrid files significantly improve data load times in both FUDGE and GIDI+. • other changes to improve load times: 'lazy parsing' such that large data arrays within GNDS are only loaded ondemand, and pre-computing summed transfer matrices rather than requiring that the sums be computed at load time by GIDI+.
More recent e↵ort has also been focused on processing the unresolved resonance region (URR) to generate probability tables and Bondarenko self-shielding factors. This update was not complete in time for the FUDGE-6.0 release, but is nearly complete and will be available soon.
The thermal upscatter correction in FUDGE is also being revised after users pointed out problems with the correction at higher temperatures (e.g. 30 keV/k B Maxwellian). A. Kunen has proposed an alternate model that is being tested and may be included in the next FUDGE release [15].
Another important focus for the FUDGE developers will be to expand the documentation and tutorials to help new users get started with FUDGE. Work is ongoing towards building Jupyter notebook-based tutorials to demonstrate how to automate some common tasks with FUDGE.

Conclusion
GNDS has been accepted by an international collaboration as the new standard for storing nuclear data, replacing the long-time standard ENDF-6. FUDGE provides a powerful platform for generating, modifying, checking and processing GNDS nuclear data. Lawrence Livermore National Laboratory has switched to using GNDS, FUDGE and GIDI+ as the main tools for storing and using nuclear data, and has released FUDGE and GIDI+ as open source codes in hopes that they may be useful for other institutions wishing to start using GNDS. Development on FUDGE and GIDI+ is ongoing, and the developers appreciate feedback from users.

Special acknowledgment
The authors wish to recognize the extensive contributions of Gerry Hedstrom, who passed away during the summer of 2022. Gerry had a long career working with nuclear data at LLNL, and continued to contribute to the Merced code (used by FUDGE to compute transfer matrices) until shortly before his death.