Requirements for a next generation nuclear data format

OECD/NEA/WPEC SubGroup 38∗ (Dated: April 1, 2015)

This document attempts to compile the requirements for the top-levels of a hierarchical arrangement of nuclear data such as is found in the ENDF format. This set of require- ments will be used to guide the development of a new set of formats to replace the legacy ENDF format.

CONTENTS H. Examples of covariance data usage in this hierarchy 48

I. Introduction 2 VII. Required low-level containers 49 A. Scope of data to support 3 A. The lowest-level 51 B. How to use these requirements 4 B. General data containers 52 C. Main requirements 4 C. Text 53 D. Hierarchal structures 5 D. Hyperlinks 53 E. Complications 6 1. Is it a material property or a reaction property? 6 VIII. Special reaction case: Atomic Scattering Data 54 2. Different optimal representation in different A. Incoherent Photon Scattering 55 physical regions 7 B. Coherent Photon Scattering 55 3. Ensuring consistency 7 4. Legacy data 7 IX. Special reaction case: Particle production or Spallation 5. Special cases 8 reactions 56

II. Common motifs 8 X. Special reaction case: Radiative capture 56 A. Documentation 8 B. What data are derived from what other data? 11 XI. Special reaction case: Fission 57 C. Product list elements 13 A. Introduction 57 D. elements 13 B. Existing ENDF format 58 E. and elements 16 C. Fission format requirements 58 F. Multiplicities 17 XII. Special component case: Fission Product Yields 59 III. Particle and/or material properties database 18 A. Introduction 59 B. Existing ENDF format 59 IV. One evaluation 20 C. Detailed FPY format requirements for GND 60 A. Reaction designation 23 D. Discussion of possible implementations 61 B. The collection of reactions: 24 C. The element 24 XIII. Special reaction case: Large Angle Coulomb Scattering D. Differential cross sections: dσ(E)/dΩ and (LACS) 62 dσ(E)/dΩdE 26 E. Integral cross sections: σ(E) 27 XIV. Special reaction case: Thermal Scattering Law 64 F. Defining data styles 27 A. Theoretical Background 64 G. Derived reactions 27 B. Gaussian approximation of the self part of the H. Resonances 29 scattering kernel 66 1. Designating channels 32 1. Coherent Elastic Scattering 67 2. Resolved Resonances 34 2. Incoherent Elastic Scattering 68 3. Unresolved Resonances 36 3. Incoherent Inelastic Scattering in the Short 4. Correcting cross sections and distributions with Collision Time Approximation 68 background data 36 XV. Additional derived data elements for applications 68 V. Grouping together evaluations 37 A. General Transport Data 69 A. Defining a collection of evaluations 37 1. Product average kinetic energy and forward B. “Effective” or “Meta” evaluations 37 momentum 69 2.µ ¯lab(E) 69 VI. Covariance data 41 3. CDF’s from PDF’s 69 A. Covariance Definitions 41 4. Probability tables in the URR 69 B. Covariance of continuous functions 43 B. Grouped Transport Data 70 C. Covariance of multi-dimensional functions 44 1. Inverse speed 71 D. Covariance andDRAFT correlation matrices 44 2. Multiplicity 71 E. Weighted sums of covariance 45 3. Q-value 71 F. The “Sandwich Formula” 46 4. Projectile kinetic energy and momentum 71 G. Monte Carlo Sampling 47 C. Production data 71 D. Damage cross sections 72

XVI. Prototyping Functions 72

∗ Edited by D.A. Brown ([email protected]) Acknowledgments 73 2

A. Graphical notation 74 • The format should be as flexible as possible so that existing libraries could be translated into the stan- B. List of requirements 75 dard format and so that the format can be extended C. Terminology 77 to meet future needs.

D. Contributors 88 • This standard format would be the link between a data library and the processing codes. References 90 • It was also suggested that a center be created and tasked with the development and maintenance of I. INTRODUCTION the new format called the Evaluated Nuclear Data File (ENDF). This center would also collect and It was realized as far back as the Manhattan project distribute data. that collections of nuclear cross-section data were needed. A preliminary version of the ENDF format was sent for These collections evolved into the “Barn Book” (Hughes, review and comment. At the final meeting at Brookhaven 1955) first sponsored by the United States Atomic En- on May 4-5, 1964, the 22 attendees discussed changes ergy Commission. By 1963, there were many nuclear to ENDF and settled on a final version. The descrip- data libraries such as the United Kingdom Nuclear Data tion of the system (referred to as ENDF/A 1) was doc- Library (UKNDL) (Parker, 1963) from Ken Parker at umented in the report BNL-8381 (Honeck, 1965). The the Atomic Weapons Research Establishment, Atomic initial ENDF/A library contained an updated version of Energy Authority in Aldermaston, UK; the fast reactor the UKNDL library and evaluated data from a number data library from Joe Schmidt at the Institute for Neu- of different laboratories. As ENDF/A did not contain tron Physics and Reactor Technology, Nuclear Research full evaluations, there was also a need for evaluated nu- Center, Karlsruhe, Germany; the NDA library from Herb clear data to be used for reactor design calculations. The Goldstein at Nuclear Development Associates, in New description of this system (referred to as ENDF/B) grew York; and the Evaluated Nuclear Data Library (ENDL) out of ENDF/A and was documented in the report BNL- from Bob Howerton at the Lawrence Radiation Labo- 50066 (Honeck, 1966). Whereas the format of ENDF/A ratory in Livermore, California. Each laboratory devel- was flexible, allowing data centers to produce and accept oped its own storage and retrieval schemes for its data data in a variety of representations, the format of END- and in many cases libraries were hard-wired into simula- F/B had to be simple and mathematically rigorous to tion codes. As a result, reactor designers and other data facilitate the development of the supporting infrastruc- users could not use new cross-section data, even though tures including data processing, integration and plotting. in some cases the data were available for five or more Nearly 50 years later, we are revisiting the format and years (Goldstein, 1968). Furthermore, dissimilarities in its specifications in order to modernize it. The funda- the internal formats of each lab kept data users from mental need for data has not changed in this time, but reconciling differences in calculated values for the same the computational tools we have available are much more reactor configurations. advanced and our physics understanding has advanced as There was a need for a common mechanism for inter- well. The kinds of data we need to store have also grown comparison between these systems. Following a discus- markedly. In November 2012, a Working Party on Evalu- sion between Henry Honeck (Brookhaven National Lab- ation Cooperation SubGroup, WPEC-SG38, was formed oratory), Al Henry (Westinghouse) and George Joanou (WPEC Subgroup 38, 2012) to coordinate the modern- (General Atomics) at the Colony Restaurant in Wash- ization of the ENDF format and supporting infrastruc- ington, D.C, the Reactor Mathematics and Computa- ture. At that meeting, the following seven tasks were tion (RMC) Division of the American Nuclear Society organized (WPEC Subgroup 38, 2013a,b): (ANS) was requested to sponsor two meetings to discuss a plan to develop this mechanism. Honeck, the chairman Requirement 1: WPEC Subgroup 38 tasks of the Division’s sub-committee on Evaluated Nuclear Data Files, held these meetings. This effort culminated 1.1 Low level data containers in a meeting of 18 representatives from 15 US laborato- 1.2 Top level reaction hierarchy ries in New York City on July 19, 1963 to review cross 1.3 Particle property hierarchy section libraries and discuss means for exchanging these 1.4 Visualization, manipulation and processing libraries. A sub-committeeDRAFT was appointed to meet in tools Hanford on September 18-20, 1963 to examine library formats in more detail. The conclusions of these meet- ings were:

• There was a need for a standard format for evalu- 1 ENDF/A referred to both a format and to a library stored in ated nuclear data. that format. 3

1.5 API derived data in a standardized structure facilitates inter- 1.6 Testing and quality assurance laboratory comparison of processed data. Additionally, 1.7 Governance the format must support uncertainties, generally given as covariance tables, on all these quantities. This document attempts to compile the requirements The data to be stored are typically a balance between for a hierarchical arrangement of nuclear data, such as is what an evaluator can provide and what a particular ap- found in the ENDF format, that addresses WPEC Sub- plication needs. Therefore, it is useful to look at the most group 38 Tasks 1.1, 1.2 and 1.3. This set of requirements common use cases: will be used to guide the development of the specifications • Particle Transport: For transport, cross sections for a new structure to replace the legacy ENDF format. for all reactions that are energetically possible over The requirements do not define the format used to store a given range of incident energy E must be stored, the data. Instead, the structure can be stored in any along with a list of outgoing reaction products with nested hierarchical meta-language, ensuring that future the products’ multiplicities and probabilities for users and developers of nuclear data will be able to store outgoing energies and angles. Data may be para- data in whatever medium is available in the future. metric (for example, Watt spectra for storing en- In this document, we will commonly refer to the Gen- ergy distributions or resonance parameters for stor- eralized Nuclear Data (GND) format and the Fudge code ing both cross sections and distributions), or they system, two projects initiated at LLNL (Mattoon, 2012; may be given in tabular form. Some of these data Pruet, 2006). GND is a hierarchical nuclear data for- are temperature-dependent and the temperature mat that is the prototype for the system WPEC-SG38 must be denoted. Additionally, different solution is creating. Fudge is the first code framework that can methods (deterministic or Monte Carlo transport) interpret and manipulate GND formatted data. Neither have different derived data requirements: the GND examples nor the names or arrangements of data in the figures of this document are “set in stone”; – Deterministic transport: In addition to all are expected to evolve in the process of developing the cross sections, deterministic transport codes new format and infrastructure. require transfer matrices (which store the The authors of this document have discussed the re- double-differential cross section for each reac- quirements broadly with members of the nuclear data tion product as a Legendre expansion where community and attempted to capture the ideas and needs each term is averaged over incident and outgo- from a wide range of applications and perspectives. With ing energy ranges), as well as energy and mo- a high degree of confidence we can say we did not capture mentum deposition cross sections. Although all of them. One can surely find one more case of “what these quantities are derived from the cross sec- about ...”. However, we believe this document reflects a tion, multiplicity and distribution data, the comprehensive view of our communities’ “best practices” transfer matrices in particular are computa- and provides the map to an ENDF modernization that tionally intensive to calculate, so the new will stand the test of time. There are significant risks structure needs to be capable of storing them to building anything by committee: the joke goes that for re-use and exchange. an elephant is a mouse built by committee. History will – Monte Carlo transport: A single cross sec- judge the success or failure of this effort by the adoption tion for a given incident energy is not always and longevity of its product. sufficient for Monte Carlo simulations. In par- ticular, the rapidly fluctuating cross section in the unresolved resonance region can often A. Scope of data to support be better described as a probability distribu- tion of cross sections. The new data format A nuclear reaction data library evaluation describes therefore needs to support storing cross sec- an incident particle (called a projectile) impinging on tion probability tables. The new format may target. The target may be a single atom or atomic nu- also need to support storing other cumula- cleus, or a collection of atoms with which the projectile tive distribution functions (CDFs) for sam- reacts. The projectile may be the traditional n, p, d, t, pling outgoing particles. 3He, α, γ, or e− or anyDRAFT other single (composite) particle (e.g., 12C, muon or pion). The ultimate goal for a new • Transmutation/Isotope Burn-Up: For iso- structure is that it must support storing self-consistent, topic production and depletion, cross sections and complete evaluations along with their derived data. The optionally outgoing spectra for chosen reactions derived data includes things like transfer matrices and en- that are energetically possible over a given range ergy depositions along with the parameters (e.g., group of incident energy E are needed. In addition, the boundaries and fluxes) used in their derivation. Storing decay half-lives and product branching ratios must 4

be known for all nuclei to enable the time depen- have had discussions2 among ourselves and with other dent calculation of the isotope inventory. members of the nuclear science community. We have captured many of these discussions in this text so that • Astrophysical network calculation: In an as- future users of the data and formats can understand our trophysical network, one needs isotopic accretion reasoning. Much of this discussion has been already inte- and depletion cross sections. These data may be av- grated into the requirements. However, there were other eraged over Maxwellian neutron spectra to simulate questions that required further discussion and these are the neutron flux in an astrophysical environment. formatted as follows: Astrophysical networks also involve reactions with Discussion point: charged particle projectiles – not just neutrons – and may required detailed knowledge of charged- Users didn’t get this point. particle interactions in plasmas. Resolution: • Web Retrieval: For archival, there are no com- We added an example to clarify it. pleteness requirement as the data will not be used in applications. The data will most likely only be visualized. That said, visualization requires a Also, during the effort to create this and its companion pointwise representation for many data types. documents, it became clear to us (the authors and other contributors) that we often do not agree on the mean- • Uncertainty Quantification (UQ): UQ appli- ing of a concept. Given that the ENDF format manual cations encompass all of the above use cases. The (Trkov, 2009) is several hundred pages long and encapsu- defining difference is the need to also specify un- lates decades of accumulated knowledge, it is no surprise certainties/covariance on aspects of data. One can that we are all not intimately familiar with all of its in- then either generate statistical realizations of these tricacies. Therefore, we provide a glossary in appendix data (if one is adopting a Monte Carlo approach C. to UQ) or one can use the “Sandwich Formula” (if We also tend to use XML in examples and to denote one is using a deterministic approach). elements in the hierarchy. This is only a matter of con- venience as the data should be serializable in any nested For all use cases, data will need to be documented. hierarchical meta-language (e.g., HDF5, ROOT, JSON, Therefore we will need facilities for documenting data Python classes). We denote major nodes/elements in clearly, concisely and as machine and human readable as the XML element-like notation (e.g., ) and possible. In addition, version information for the format, attributes of these nodes/elements without the brackets the documentation, the evaluation itself, the codes used (e.g., attribute). in evaluation, etc. all need to be stored. Finally, we note that as we list and discuss require- ments, we encounter suggestions for test cases for either data or supporting codes. This are marked up as follows: B. How to use these requirements SUGGESTED TEST: This is an example test.

This document is a list of the requirements for the C. Main requirements new format. It is not the specifications of the format. At times the details of the requirements may constrain the At the highest level, there are some overarching goals actual specifications so much that the requirements may that we believe a new format should achieve. These goals seem to be specifications. Other times the requirements represent the most broadly held beliefs that guide all sub- will be broad and may be left to interpretation or may sequent requirements. The main goals are: have several possible implementations. In this document, requirements are called out and Requirement 3: Main uniquely numbered so that they can be clearly referenced in later work. A requirements list is formatted as follows: 3.1 The hierarchy should reflect our understand- ing of nuclear reactions and decays, clearly Requirement 2: An example and uniquely specifying all such data. DRAFT3.2 It should support storing multiple represen- 2.1 Don’t be evil tations of these quantities simultaneously, for 2.2 Respect the user 2.3 Let the evaluator express themselves clearly

In the process of developing these requirements, we 2 And they were sometimes contentious 5

tentious. Care should be taken to ensure that names example evaluated and derived data. align themselves with generally accepted definitions. At 3.3 It should support both inclusive and exclusive the higher levels, these names should convey the phys- reaction data, that is discrete reaction chan- ical essence of the data, for example crossSection or nels as well as sums over multiple channels. emissionDistribution. At the lower levels, they should 3.4 It should use general-purpose data contain- convey the type of data being stored, for example points ers suitable for reuse across several application defining a piecewise continuous curve or vectors defining spaces. bands in a sparse array. 3.5 It should eliminate redundancy where possi- There are two significant questions regarding the nam- ble. ing of nodes: the choice of language and the character 3.6 As a corollary to requirements 3.1 and 3.2, set used to encode them. These are pragmatic choices. multiple representations of the same data The character sets available across storage systems vary should be stored as closely together in the hi- greatly. Choosing a restricted set will enable a broader erarchy as feasible. adoption of this structure into working implementations. As many of these storage systems allow only ASCII char- Some of these goals may seem contradictory. For exam- acters, or only a limited set thereof, the allowed language ple, allowing multiple representations while at the same and character set need to be clearly defined. time eliminating redundancy appear to be conflicting The format must store data and information qualifying goals. However, derived data are not redundant: they the data. The qualifying information are typically known reflect the choices of the processor and needs of partic- as meta-data. There are values that are clearly data; for ular applications (e.g., group boundaries and fluxes) in example cross sections, resonance parameters or emission addition to the original evaluated data. distributions. There are also values that are clearly meta- It is up to each evaluated data project to determine data; for example the number of point-wise energy/cross specific requirements, such as the completeness, of the section pairs, the units for values or the frame of reference data to be stored in a particular library. Similarly, it is up for a particle emission. Hierarchal storage systems typi- to the data processor to decide how to process the data, cally allow attribute names/values to be associated with but the resulting processed data need to be stored in a a node. In general, the format should store meta-data as common structure to facilitate exchange and comparison. attributes to nodes and data within the node itself. Crafting a structure that is capable of balancing all of the At the bottom of such structure are the actual data. goals in requirements: 3 is the task at hand. These are general numeric—real, integer, complex— values with documentation, annotation or meta-data pro- vided as text. At some point these values must be laid D. Hierarchal structures out sequentially in a storage system; that is, they must As implied in the first requirement for the new format, be written into a file for archival storage or exchange. At data shall be stored in a hierarchal structure. The design this lowest level, it is vital that the beginnings and ends choices made in the development of the original ENDF of each component of the data be clearly delineated and format enabled the community to shoe horn data onto that the necessary mathematical transformations and in- punch cards at the expense of obfuscating even the sim- herent physical meaning of the data be defined by the plest things such as determining when one floating point structure containing these data. Anyone who has ever number ends and another begins. The inability to read struggled to determine where the data they need are a data file without a deep understanding of the ENDF stored inside a large data file will understand just how format leads to issues with quality assurance. Neverthe- important this requirement is. less, there is a common sense arrangement of data that Done well, complexity reveals itself nothing more than reflects both our understanding of particle transport and elegant simplicity. Herein each data structure should reaction physics. Capturing and encoding that arrange- itself consist of its basic building blocks: well-defined, ment within the formal structure will vastly improve the well-formed, universal in specific application, and built usability of the data for those with little knowledge of our from such lower level blocks as needed down to some final formats. This is an obvious benefit to the community at atomic component. Humans are by nature organizational large, enabling more people to work more effectively and animals, seeking to find order in chaos. with greater assuranceDRAFT that they are corectly using the Requirements related to the hierarchical structure are: correct and best data for their applications. Hierarchal storage defines itself by means of nodes ex- Requirement 4: Hierarchal structures isting as parents, siblings and children spanning logical levels. We require a means of identifying these nodes 4.1 Data shall be stored in a hierarchal structure and do so by providing them names. These names are, to some degree, arbitrary and thus likely to be con- 6

4.2 At least one implementation of the format • For atomic nuclei: shall be made using text, not binary, storage 4.3 Node names should be used to convey meaning – target mass 4.3.1 High-level nodes should convey physical – number of neutrons, protons (and maybe even meaning hyperons!) 4.3.2 Low-level nodes should convey mathe- matical or functional meaning – nuclear level schemes (energies, spins, parities, 4.3.3 Node names shall use a restricted char- ...) acter set to work across varying storage – level lifetimes, level widths systems 4.4 Attributes should be used to store meta-data – gamma and decay branching ratios from par- 4.4.1 Attribute names shall use the same re- ticles emitted during the de-excitation of ex- stricted character set as node names cited states of a nuclear level 4.5 Well-reasoned components of numerical data – emission spectra from these nuclear decays shall be stored separately 4.5.1 Necessary transformations into appropri- • For elements: ate mathematical form shall be stored lo- cally – Z 4.5.2 Physical meaning and units of numeric data may be stored locally or inherited – Chemical symbol and name

• For atoms/ions: E. Complications – mass As we develop requirements for a new nuclear data hierarchy, we naturally encounter thorny issues that must – atomic shell properties (binding energies, be dealt with before specifications can be authored. Here spins, parities, ...) we discuss several issues would, if not addressed early on, – X-ray decay and branching ratios from excited frustrate the development of the specifications. states Differences in opinions and advancement in under- standing can lead to a desire to restructure existing data – level lifetimes and widths layout. As we consider solutions to these issues, we must – emission e− spectra from the internal conver- strike a balance between keeping the legacy solution – sion of gamma rays emitted from nuclei that is, the ENDF-102 (Trkov, 2009) with which the nu- clear data community is already familiar – and the desire – charge state to reach for new solutions. We also comment that we will need to strike a balance in how deeply to nest the hier- • For composite materials (as encountered in thermal archy since some storage schemes perform better with a neutron scattering): flatter hierarchy (e.g., HDF5) even though a deep hierar- chy may make sense for organizing the data more clearly. – target density (at STP) – target stoichiometry 1. Is it a material property or a reaction property? These lists may be amended as needed in the discussion Some kinds of data can be viewed as reaction- below and a deeper discussion of them will be presented independent properties of a target material. A case in in the requirements for the material properties database. point is the gamma branchings from an excited nuclear Indeed, it was recognized at the December 2013 WPEC state of a nucleus. An excited nucleus decays via a meeting that, in order to ensure consistency of masses, gamma cascade through the lower levels of the nucleus in Q values, levels and gammas within an evaluation, an accordance with the tabulatedDRAFT gamma branchings, inde- external database is needed to perform this role library- pendent of whether it was formed in a neutron induced wide. This database addresses main requirement 1.3 and reaction or fission or any other process that leads to the is covered in section III. same compound system. A separate particle properties database also pro- Given this, we view all “particle/material properties” vides us a mechanism to store the ENDF/B-VII.0 and as data that are independent of the excitation mechanism. ENDF/B-VII.1 Decay and Atomic Relaxation subli- This includes (but is not limited to): braries (Chadwick, 2006, 2011). 7

2. Different optimal representation in different physical regions • Masses, Q values, thresholds, upper energy bounds on secondary distributions There are different optimal representations of data in • Normalization conditions (on probability distribu- different physical regions. For example, at low energies tions, multiplicity tables, etc.) (i.e., in the resolved resonance region), neutron scatter- ing is best described with an R matrix approach, whereas • Energy and momentum balance above the (n, n0) threshold it is best described via tabu- lated data as shown in Figure 1. This implies for example • Energy ranges of tables within a reaction and be- that tween different physical regimes • Different physical regions may require us to change • Gamma branchings (that is, an excited state should our concept of what a target is (e.g., fast neutrons have the same gamma-decay paths open no matter see a single nucleus while thermal neutrons may how it was produced) (in)coherently scatter off many atoms in a material) • Resolved and unresolved resonance regions and the • Different macroscopic environments require us to fast reaction region change our description of microscopic data (e.g., Doppler broadening due to temperature effects) • Original and processed data • Different incident energies affect what particles are Between evaluations, we must also ensure consistency be- produced (e.g., pre-equilibrium, multifragmenta- tween tion, particle production, spallation) • Fission product yields and decay data linkage This fact was already recognized in the design of the legacy ENDF format and is a reality we too must confront • Fast reaction region and the particle production re- (Trkov, 2009). Hence, we not only must consider different gion if they are stored in separate evaluations as is optimal representations (e.g., resonance parameters) in the case in for example JENDL and the JENDL-HE different physical regions, but we also must consider high energy library. • Different alternate representations (e.g., resonance • Masses and other material properties parameters versus reconstructed pointwise cross • Covariances and mean values between data com- sections) mon to both the Neutron Standards (Carlson, • The matching (and potentially overlap) between 2009) and CIELO projects (Chadwick, 2014). representations Some of these can be handled with a simple hyperlink. • A mechanism to “glue” them together, especially Others may require capability within external process- in cases where the concept of a target or reaction ing/manipulation infrastructure. In the following discus- changes dramatically (e.g., thermal neutron scat- sions, we will point to features of the hierarchy that en- tering on molecules transitioning to high energy able maintaining consistency. neutron resolving the nuclei in the atoms of the Material properties are a special case where inconsis- molecule) tencies may need to be tolerated. In particular, when dealing with legacy ENDF evaluations, there is no guar- antee that the same masses or level schemes are used 3. Ensuring consistency consistently throughout an evaluation. As such, we may need to override any external material properties As we design the format(s) and supporting infrastruc- database with local versions within an evaluation. ture, it is important to maintain internal consistency of the data. Within an evaluation, we must ensure at the very least consistency between: 4. Legacy data • Cross section sum rules More than six decades of work have gone into the cre- – Summing to the total cross section ation of the nuclear data libraries and formats. Many – All (n, n0) crossDRAFT sections sum to total inelastic very old data files are still in production and are needed (ditto for other similar reaction types); similar for specific applications. These data must be supported to MT=3 until such time as they can also be updated. The following requirements reflect the need to support • The sum of the prompt nubar and all delayed legacy data: nubars must equal the total nubar in a fission reac- tion 8

(smooth) thermal RRR URR (smooth) fast

FIG. 1 Cartoon of energy regions in a neutron induced reaction. The high energy region labeled “(smooth) fast” is usually handled in a very different way than the low energy regions where the R matrix approach applies.

Requirement 5: Legacy data • Charged particle reactions (Section XIII) • Atomic data (Section VIII) 5.1 Grandfather in all valid ENDF data in cur- rently supported ENDF-102 Version 6 for- mats. II. COMMON MOTIFS 5.2 Correct, wherever possible, ENDF mistakes and inconsistencies. In the sections to follow, we will describe several re- 5.3 Have a process for deprecating data or formats peated patterns in the proposed data hierarchy. These that must be supported but that we intend to repeated patterns or motifs include documentation el- phase out at some later date. ements (see subsection II.A), lists of reaction products 5.4 “We don’t have the resources to shoot all of and the sub elements of a specification (see our users in the foot. So we should enable our subsections II.C, II.D, II.E, II.F) and more complicated users to do it themselves.” (Beck, 2005). constructs detailing what data is derived from what other data (see subsection II.B). We note two other reoccur- ring “patterns”: covariance data (described in section 5. Special cases VI) and Fission Product Yields (FPY). FPY data ex- ists for both induced reactions (for example, the Neu- The ENDF/B-VII.0 and ENDF/B-VII.1 libraries tron Fission Product Yield sublibrary in ENDF/B-VII) (Chadwick, 2006, 2011) contains 14 separate sub libraries and as decay products from spontaneous fission (in both covering a variety of reaction data types. All of these the ENDF/B-VII Decay and Spontaneous Fission Prod- must be covered by the format whose requirements we uct Yield sublibraries). FPY format requirements are are drafting. However several of the data have special detailed in section XII. We comment that the motifs de- requirements that require further discussion: scribed here are also needed for the particle properties DRAFTdata. • Particle production (Section IX)

• Radiative capture (Section X) A. Documentation • Fission (Sections XI and XII) The documentation for an evaluation or part of an eval- • Thermal scattering law data (Section XIV) uation is in a way the most essential piece of information. 9

From it, we must be able to determine who performed the (Pritychenko, 2011), NSR keywords can be placed here. evaluation and how they did it. This is essential both Alternatively, keywords for web searching may be placed for attributing credit (and blame ;)) and for debugging here. problems in an evaluation. This also aids in addressing Continuing, the elements