Development and Verification of Capability for Processing the Generalised Nuclear Database Structure (GNDS) in Nuclear Data Processing Code NECP-Atlas

. The latest evaluated nuclear data libraries, including ENDF/B-VIII.0, TENDL2019, all have two formats, the Evaluated Nuclear Data File (ENDF-6) nuclear data format, and the Generalised Nuclear Database Structure (GNDS) format. The first official public documentation of all of the options for storing data in GNDS was released by the Working Party on International Nuclear Data Evaluation Co-operation(WPEC) of the Nuclear Energy Agency. The generalized derived class is designed to be compatible with ENDF-6 and GNDS in nuclear data processing code NECP-Atlas, and the GNDS-Toolkit is developed in NECP-Atlas to parse and convert GNDS. ACE format library and multi-group library are generated based on GNDS, and they are used in the Monte-Carlo code and deterministic based code to compare with ENDF-6. The numerical results show that GNDS libraries can be processed by NECP-Atlas competently to generate specific format library and the difference in ENDF-6 and GNDS is very small.


Introduction
Generalized Nuclear Database Structure (GNDS) is a new format to store evaluated nuclear data, and it is more modern than the traditional ENDF-6 format. It was originally proposed by Lawrence Livermore National Laboratory (LLNL) as an internal data format [1] . The main advantages of GNDS are to: 1) GNDS is written in a modern format than ENDF-6. ENDF-6 is based on legacy technology from an era when computers utilized punch-card readers, so it persists in an old-fashioned 80-column card image [2] . GNDS format is given in the metalanguages, including XML, HDF5, JSON, and so on. Based on these meta-languages. 2) GNDS stores more nuclear data than ENDF-6.
GNDS can simultaneously store various evaluated nuclear data or derived data that cannot be stored in the ENDF-6 format. For example, GNDS can store resonance parameters with background cross sections like ENDF-6, and it can also store the reconstructed pointwise data at the same time. 3) GNDS has more general data containers to store more complex data easily. The ENDF-6 format defines HEAD CONT LIST TAB1 TAB2 INTG(only used to store partial covariance data of resonance parameters) records to store all evaluated nuclear data [3] . The GNDS format defines a more general data container to store more data, including constant1d, XYsNd(N 1), regionsNd(N 1), array, table, and so on. 4) GNDS expresses the hierarchical structure more clearly than ENDF-6. In the ENDF-6 format,  [4] , and most nuclear data, including NJOY [5] , AMPX [6] , FRENDY [7] , GALILEE [8] are developing this function to process GNDS format.
The purpose of the present work is to present the development of the capability of processing the GNDS format evaluated nuclear data in NECP-Atlas. Firstly, the code of NECP-Atlas is adjusted to be compatible with the ENDF-6 and GNDS format; Secondly, the code of parsing the GNDS format libraries (version 1.9) is developed in NECP-Atlas, and the application libraries, including ACE libraries and multi-group libraries, are generated based on the GNDS format libraries; Finally, the different benchmarks are calculated based on GNDS format, and the results are compared with ENDF-6 format to verify the code.

Methods
In the present work, a Fortran derived data type named Root_Lib which was originally designed according to the hierarchy of the ENDF-6 format is extended to be compatible with the two formats. The flowchart of the new version of NECP-Atlas is shown in Fig. 1. Both ENDF-6 and GNDS format libraries are converted into Root_Lib, and Root_Lib is used for the data transfer between different processing modules. The functions and the applied methodologies for each processing module are identical to our other works [9] . A new toolkit named GNDS-Toolkit (shown in the green box in Fig.  1) is developed to parse and convert the GNDS format evaluated nuclear data, and store the data into Root_Lib finally. In Root_Lib, there are several variables to describe the properties of the projectile and the target. In the ENDF-6 format library, the ZA number for a target with atomic number Z and mass number A is defined as ZA=1000×Z+A, and the ZA number can be inferred by the id of the target in the GNDS format. The AWR variable is the relative neutron mass of the target. In the GNDS format library, it is not given directly, but it is calculated according to the target mass and the neutron mass. The derived data type variable, datas, is used to store the nuclear data for each temperature. It is defined by the derived data type of root_type as shown in Fig. 3:   Fig. 3. The structure of derived data type root_type In root_type, the current temperature, and the number of reactions for this temperature are given. The derived data type variable,mftp_map is a Hash map, the Hash key is defined as: key=MF × 1000 + MT (1) The Hash value is defined as the index of the corresponding reaction in the derived data type varaiable, mftp array. The variable, mftp, does not need to be stored in a specific MF/MT order like the ENDF-6 format. Based on the Hash map, some non-ENDF allowed reactions can be stored in Root_Lib, such as the reconstructed cross sections.
The derived data type variable, mftp is designed to store the data for each reaction. The derived data type of data_base_type used to define mftp is described as shown in Fig. 4: The structure of derived data type data_base_type In mftp, there are several basic derived data types including head_type, cont_type, list_type, tab1_type and tab2_type. These types are designed according to the HEAD, CONT, LIST, TAB1 and TAB2 records in ENDF-6, and ENDF-6 format libraries can be converted into Root_Lib easily.

GNDS-Parser
GNDS-Parser is developed to read and parse the GNDS/XML format library. In the GNDS format library, many comments are not necessary to be parsed. If all the data were parsed after it was read into the memory, a lot of time would be wasted. The best way is to read the data and parse the data at the same time. Based on this reason, the StAX method [10] is used to parse GNDS/XML library. A stack is used to ensure the integrity of GNDS/XML libraries and sort out the hierarchy. Fig. 5 shows an example of an XML file, and Fig. 6 shows the use of this stack to parse the XML file in Fig. 5. Firstly, tag <a> is read, and the element "a" is added to the stack; Secondly, tag <b1> is read, and the element "b1" is added to the stack; Thirdly, the element "c" is added to the stack as "a" and "b1"; Then, the end tag </c> is read, and the element "c" is removed from the stack…… Finally, end tag </a> is read, and the element "a" is removed from the stack. Baed on the stack, the relationship of "a", "b1", "b2" and "c" can be described clearly, as shown in Fig. 6.
Based on the above StAX method, GNDS/XML format library is converted into a temporary list, and all data is converted into GNDS_Base finally, which is written in the standard Fortran 2008 with the objectoriented method. GNDS_Base further includes six derived data types: GNDS_Styles, GNDS_Pops, GNDS_Resonance, GNDS_Sums, GNDS_Reactions, GNDS_Tsl. These types correspond to styles node, Pops node, resonances node, reactions node, Sums node, and thermalScattering node in the GNDS format respectively.

GNDS-Converter
The data stored in GNDS_Base is then converted and transferred into Root_Lib by GNDS-Converter. The concept of MF number is not used in the GNDS format, so the data in GNDS_Base must be transferred to the corresponding MF number. In GNDS-Converter, a series of subroutines are developed to achieve this work. The subroutines and the flowchart of the GNDS-Converter are shown in Fig. 7. Firstly, the basic data including the mass, the ZA number, and the relative neutron mass of the target is converted from GNDS_Base into Root_Lib. Secondly, sections in the MF=1 are converted into Root_Lib. In the ENDF-6 format, MF=1 includes four main sections: MT=452, 455, 456 and 458, representing the total fission neutron multiplicity, delayed fission neutron multiplicity, prompt fission neutron multiplicity, and components of energy release due to fission reaction, respectively. Thirdly, the data stored in MT=151 of MF=2 is converted, including the scattering radius, the resolved resonance region (RRR) parameters and the unresolved resonance region (URR) parameters. Fourthly, the data stored in MF=3 section is converted into Root_Lib. MF=3 section stores the smooth background cross sections of the reactions, and the reconstructed and linearized cross sections are converted into our internal MF number MF93 at the same time. Fifthly, the distribution data of the secondary particles of each reaction is converted into Root_Lib. In the ENDF-6 format, the distribution data is usually stored in MF=4, 5 and 6. Finally, if the thermal neutron scattering law library is provided, the thermal neutron scattering law data will be converted into MF=7 in Root_Lib.

Verification
Based on GNDS-Toolkit, some common application libraries in specific formats could be generated based on GNDS libraries. To verify the GNDS-Toolkit, the ACE format libraries for Monte Carlo codes, NECL format libraries [11] for deterministic lattice physics simulation For comparison, these application libraries are also generated based on the ENDF-6 format libraries of ENDF/B-VIII.0. Fig. 8 shows the flowchart of generating ACE libraries or multi-group libraries.
The flowchart of generating ACE libraries or multigroup libraries The Monte Carlo code NECP-MCX [12] is used to calculate the ICSBEP benchmarks [13] to verify the ACE libraries. The calculated benchmarks are listed in Table  1, and the results show in Fig. 9. most of the biases of the final effective multiplication factors calculated by the GNDS format and the ENDF-6 format are less than ±5 pcm, and the maximum bias is 46 pcm.  In order to verify GNDS-Toolkit in the deterministic based reactor physics calculations, the lattice physics code LOCUST [14] is used to calculate VERA-2 benchmarks and VERA-1B benchmark [15] . The keff results of VERA-2 benchmarks are shown in Table 2. It can be seen that the bias between the GNDS format and the ENDF-6 format is very small.

Conclusions
GNDS-toolkit has been developed in NECP-Atlas, and GNDS libraries (version 1.9) can be processed by NECP-Atlas. In order to be compatible with the GNDS and ENDF-6 formats in NECP-Atlas, a derived data type Root_Lib is constructed to manage the memory and transfer the data between different processing modules. GNDS libraries are competent to generate specific format libraries for Monte Carlo and deterministic transport calculations, including ACE format libraries and multi-group libraries.
To verify the capability, the GNDS format library released with ENDF/B-VIII.0 is processed into ACE libraries and multi-group libraries. These libraries are used in Monte Carlo calculations. The numerical results show that the difference between GNDS and ENDF-6 is very small.