overview of proposed new format, its similarities and ... · , and elements are used primarily to...

Overview of proposed new format, its similarities and

differences compared to ENDF-6

David Brown NNDC, BNL

This talk is in some ways premature! Requirements are due now

• Draft doc nearly complete • Core of this round of subgroup results • Hopefully can finalize it this week

! Specifications are next step • Low level containers mostly done • Properties Of Particles mostly done • Top Level in progress

! Many more steps to follow: • API, • processing, etc., • documentation, • QA, • governance

It is difficult to explain all the differences when format is undergoing major revisions

This talk is in some ways premature! Requirements are due now

• Draft doc nearly complete • Core of this round of subgroup results • Hopefully can finalize it this week

! Specifications are next step • Low level containers mostly done • Properties Of Particles mostly done • Top Level in progress

! Many more steps to follow: • API, • processing, etc., • documentation, • QA, • governance

It is difficult to explain all the differences when format is undergoing major revisions

That said, we have a nearly complete prototype (GND) and expect final format to be very similar

These are the requirements that we’ve gathered from you, the nuclear data community

4

DRAFT

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 hierarchicalarrangement 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 legacyENDF format.

CONTENTS

I. Introduction 2A. Scope of data to support 3B. How to use these requirements 4C. Main requirements 4D. Hierarchal structures 5E. Complications 6

1. Is it a material property or a reaction property? 62. Di↵erent optimal representation in di↵erent

physical regions 73. Ensuring consistency 74. Legacy data 75. Special cases 8

II. Common motifs 8A. Documentation 8B. What data are derived from what other data? 11C. Product list elements 13D. <product> elements 13E. <distributions> and <distribution> elements 16F. Multiplicities 17

III. Particle and/or material properties database 18

IV. One evaluation 20A. Reaction designation 23B. The collection of reactions: <reactions> 24C. The <reaction> element 24D. Di↵erential cross sections: d�(E)/d⌦ and

d�(E)/d⌦dE 26E. Integral cross sections: �(E) 27F. Defining data styles 27G. Derived reactions 27H. Resonances 29

1. Designating channels 322. Resolved Resonances 343. Unresolved Resonances 364. Correcting cross sections and distributions with

background data 36

V. Grouping together evaluations 37A. Defining a collection of evaluations 37B. “E↵ective” or “Meta” evaluations 37

VI. Covariance data 41A. Covariance Definitions 41B. Covariance of continuous functions 43C. Covariance of multi-dimensional functions 44D. Covariance and correlation matrices 44E. Weighted sums of covariance 45F. The “Sandwich Formula” 46G. Monte Carlo Sampling 47

⇤Edited by D.A. Brown ([email protected])

H. Examples of covariance data usage in this hierarchy 48

VII. Required low-level containers 49A. The lowest-level 51B. General data containers 52C. Text 53D. Hyperlinks 53

VIII. Special reaction case: Atomic Scattering Data 54A. Incoherent Photon Scattering 55B. Coherent Photon Scattering 55

IX. Special reaction case: Particle production or Spallationreactions 56

X. Special reaction case: Radiative capture 56

XI. Special reaction case: Fission 57A. Introduction 57B. Existing ENDF format 58C. Fission format requirements 58

XII. Special component case: Fission Product Yields 59A. Introduction 59B. Existing ENDF format 59C. Detailed FPY format requirements for GND 60D. Discussion of possible implementations 61

XIII. Special reaction case: Large Angle Coulomb Scattering(LACS) 62

XIV. Special reaction case: Thermal Scattering Law 64A. Theoretical Background 64B. Gaussian approximation of the self part of the

scattering kernel 661. Coherent Elastic Scattering 672. Incoherent Elastic Scattering 683. Incoherent Inelastic Scattering in the Short

Collision Time Approximation 68

XV. Additional derived data elements for applications 68A. General Transport Data 69

1. Product average kinetic energy and forwardmomentum 69

2. µlab(E) 693. CDF’s from PDF’s 694. Probability tables in the URR 69

B. Grouped Transport Data 701. Inverse speed 712. Multiplicity 713. Q-value 714. Projectile kinetic energy and momentum 71

C. Production data 71D. Damage cross sections 72

XVI. Prototyping Functions 72

Acknowledgments 73

Main goals/requirements1. The hierarchy should reflect our understanding of nuclear

reactions and decays, clearly and uniquely specifying all such data.

2. It should support storing multiple representations of these quantities simultaneously, for example evaluated and derived data.

3. It should support both inclusive and exclusive reaction data, that is discrete reaction channels as well as sums over multiple channels.

4. It should use general-purpose data containers suitable for reuse across several application spaces.

5. It should eliminate redundancy where possible. 6. As a corollary to requirements 1 and 2, multiple representations of

the same data should be stored as closely together in the hierarchy as feasible.

5

What data is stored?! All reaction data stored currently in ENDF

• nuclear (n, TSL, charged particle, gammas) • atomic (e, gamma)

! Covariance data • all that is in current ENDF • requested areas (FPY, decays) • framework more general so possible

in many more data types

! Particle properties • Decay data from ENDF • Atomic relaxation data from ENDF • potential for common, unified mass table • potential for level information (most requested new feature)

… right now take from RIPL6

The need to support all legacy ENDF data is implicit

Notable features of new format(s)! Hierarchy is physics guided ! Not just one format, any hierarchical meta-format

can be used (XML, JSON, HDF5, BOF, Python) ! Use of hyperlinks ! Derived & original data may coexist in same file ! Covariance/uncertainties near data ! Unified covariance framework ! Unified resonance framework based on ENDF

LRF=7 ! Potential for centralized particle properties ! Use of generic low level structures (equivalent but

modern versions of ENDF TAB1, TAB2, etc.)7

Organization of reaction data

9

DRAFT

21

FIG. 12 Top level arrangement of an <evaluation> element. Only the documentation element is required in an <evaluation>,but <reactions>, <resonances>, and <covariances> are expected in nearly all (neutron induced) reaction evaluations. The<styles>, <particles> and <functionDefs> elements are used primarily to override or (re)define default behaviors. Finally,the <derivedReactions> and <derivedTransportData> elements are nearly exclusively for processed data.

ment. In GND this is handled with astyleInformation attribute.

15.7 Require a temperature attribute: for lowenough energy projectiles, this is a crucialpiece of information. For neutrons, Dopplerbroadening is important to determine e↵ectivereaction rates and to get self-shielding correc-tions. For astrophysical applications, the tem-perature of the plasma is needed to handlecharge screening properly.

15.8 Require ELow and EHigh attributes to specifythe energy range of validity of this evaluation.

15.9 Require an activationFlag attribute to sig-nal whether the data in this evaluation ismeant for activation or for particle transport.The two applications have very di↵erent com-pleteness requirements that, in the XML vari-ation of a format, can be enforced by checkingagainst an XSD file.

15.10 Require a file-wide <documentation>15.11 Optionally a material database to override de-

faults with values local to the evaluation (the<particles> element, described in reference(WPEC Subgroup 38, 2015a))

15.12 Optionally a place for evaluation–wide defaultstyle information such as group-structures,fluxes, etc. (see the <styles> element descrip-tion IV.F)

15.13 Optionally a place for covariance data (see the<covariances> section for more detail VI)

15.14 Optionally a <reactions> element (more on<reactions> in the subsection IV.B)

15.15 Optionally a <resonances> element (more on<resonances> in the subsection IV.H)

15.16 Optionally a <derivedReactions> element(see subsections XV and IV.G)

15.17 Optionally a <derivedTransportData>element to store application specific

“traditional” ENDF content

new content

Organization of reaction data

10

DRAFT

21

FIG. 12 Top level arrangement of an <evaluation> element. Only the documentation element is required in an <evaluation>,but <reactions>, <resonances>, and <covariances> are expected in nearly all (neutron induced) reaction evaluations. The<styles>, <particles> and <functionDefs> elements are used primarily to override or (re)define default behaviors. Finally,the <derivedReactions> and <derivedTransportData> elements are nearly exclusively for processed data.

ment. In GND this is handled with astyleInformation attribute.

15.7 Require a temperature attribute: for lowenough energy projectiles, this is a crucialpiece of information. For neutrons, Dopplerbroadening is important to determine e↵ectivereaction rates and to get self-shielding correc-tions. For astrophysical applications, the tem-perature of the plasma is needed to handlecharge screening properly.

15.8 Require ELow and EHigh attributes to specifythe energy range of validity of this evaluation.

15.9 Require an activationFlag attribute to sig-nal whether the data in this evaluation ismeant for activation or for particle transport.The two applications have very di↵erent com-pleteness requirements that, in the XML vari-ation of a format, can be enforced by checkingagainst an XSD file.

15.10 Require a file-wide <documentation>15.11 Optionally a material database to override de-

faults with values local to the evaluation (the<particles> element, described in reference(WPEC Subgroup 38, 2015a))

15.12 Optionally a place for evaluation–wide defaultstyle information such as group-structures,fluxes, etc. (see the <styles> element descrip-tion IV.F)

15.13 Optionally a place for covariance data (see the<covariances> section for more detail VI)

15.14 Optionally a <reactions> element (more on<reactions> in the subsection IV.B)

15.15 Optionally a <resonances> element (more on<resonances> in the subsection IV.H)

15.16 Optionally a <derivedReactions> element(see subsections XV and IV.G)

15.17 Optionally a <derivedTransportData>element to store application specific

“traditional” ENDF content

new content

These are the MT’s

Drill into reactions

11

DRAFT

25

FIG. 13 A possible arrangement of inclusive and exclusive reactions in the <reactions> element. Note that there are threeoptions for the double di↵erential cross section data: a) store d�(E)/dE0d⌦, b) store d�(E)/d⌦ if the outgoing energy is fixedby kinematics or c) store both �(E) and P (E0, µ|E) separately. In some cases the total cross section �(E) is not defined andone must use one of the other options.

alias.18.2.2 Option #2, parameterized dif-

ferential cross section: a<dcrossSection dOmega> element

18.2.3 Option #3, parameterized dou-ble di↵erential cross section: a<dcrossSection dOmega dE> element

18.3 The ENDF MT if appropriate (deprecated)

The distributions, etc. (and even the cross section)may have sublibrary or class specific representations.

Discussion point:

How does one implement breakup and/or multi-step reactions? The proper use of ENDF’s LR flagscheme is complex. It is used for light elementbreakup, (n,gf) reactions and reactions which lead

! Note: documentation allowed at nearly any level

! Place for obsolete data ! Various cross section

schemes, depending on need

! Detailed product distributions at lower level,but have common arrangement

Drill further into product tree

! Products have • multiplicities (they may be constant) • all distributions P(E’,m|E) (MF=6, LANGS;

MF=4,5, MF=12,13,14,15) • Reaction products can have

reactionProducts or decayProducts underneath • This enables breakup reactions • Common scheme for decay data in particle

properties and in reaction data

12

DRAFT

15

FIG. 9 Common arrangement of a product list ele-ment such as <reactionProducts>, <decayProducts> or<orphanedProducts>.

TABLE I Kinematic types for an attributefor <reactionProducts>, <decayProducts> and<orphanedProducts> elements.

kinematicType Description

two-body only two products are emitted perstep in a reaction, the products arecorrelated, and only the center-of-mass angular distribution is neededin order to calculate the double-di↵erential distribution

uncorrelated the products are treated as beinguncorrelated from each other, and acomplete double-di↵erential distri-bution is required for each product

correlated proposed

fission proposed

defined in the previous section. The product elementmust support storing (at least) a multiplicity and outgo-ing distributions.

The <product> structure is illustrated in Figure 10.We note that, in this figure, the <product> element hasboth documentation as well as all of the derived and eval-uated distributions and multiplicities corresponding tothe reaction or decay product.

Often these products further react either becausethey are an intermediate state (as in a breakup re-action), or metastable or unstable (as in decay data).To enable this, we allow the <product> element tohave both <reactionProducts> and <decayProducts>within. This enables multistep, breakup or decay reac-tions in an (hopefully) obvious way. Strictly speaking, ifone has an external (or even internal to the evaluation)particle properties database, the <decayProducts> ele-ment could be placed with the particle properties ratherthan in a <reaction> element.

Each <product> should have:

FIG. 10 Overview of a <product> element.

14

DRAFT

14

FIG. 8 An illustration of uncertainty in a data set, but derived from original data and a covariance. The coupling betweenreaction data and the corresponding covariance is handled through use of hyperlinks.

confusion for the user:

1. Outgoing neutron energy distributions are storedin an MF=5 file and angular distributions in anMF=4 file. Alternatively, both may be stored inan MF=6 file. Double di↵erential neutron data canonly be stored in an MF=6 file. Neutron multiplici-ties from fission are stored in MF=1, MT=452, 456,and 455 files.

2. Outgoing charged particle data are stored exclu-sively in MF=6 files.

3. Outgoing gamma data can be stored in MF=6 filesor in a combination of MF=12 (for multiplicities

and discrete level energies), MF=13 (productioncross sections), MF=14 (angular distributions) andMF=15 (energy distributions). Additionally, de-layed gamma data from fission are stored in MT=1,MF=460.

4. Additionally, the energy released from fission isstored in MF=1, MT=458 and is not associatedwith the produced particle.

We would like to simplify and unify these options into asimple product (and daughter) elements.Each induced reaction or spontaneous decay yields

products that are grouped in one of the list elements

Sketch how to store different versions simultaneously

! Data containers can have multiple representations of the data inside

! If possible, covariance & uncertainty must be near data

! It should be possible to store a covariance or an uncertainty and correlation

! Hyperlinks tell you what is derived

16

DRAFT

30

FIG. 15 Our proposed resonance data hierarchy.

ing relative two-body scattering states in a basis of ana-lytic wave functions, usually taken to be free ones. Wethen match wave functions on the box boundary. Thismatching is done in a clever way involving Bloch surfaceoperators on the box boundary and from this we arriveat a Green’s function of the projected Bloch-Schrodingerequation, also known as the R matrix. The elements ofthe R matrix are:

Rcc

0 =X

�

��c

��c

0

E�

� E, (2)

The factor ��c

’s are the reduced widths for channel c, E�

becomes the resonance energy (it is a pole in the Laurentseries expansion of the Green’s function) and � is theresonance (pole) index. The channel index c contains allthe quantum numbers needed to describe the two-particlestate and all of those quantum numbers are described inthe <channel> and <spinGroup> element markups be-low. The channel index may refer to an incoming or an

outgoing channel.With the R matrix, it is possible to compute exactly

the channel-channel scattering matrix Ucc

0 :

Ucc

0 =e�i('

c

+'

c

0 )p

Pc

p

Pc

0

⇥ {[1�R(L�B)]�1[1�R(L⇤ �B)]}cc

0

(3)

where the logarithmic derivative of an outgoing channelfunction is

Lc

⌘ ac

O0c

(ac

)

Oc

(ac

)=

rc

@ lnOc

@rc

�

r

c

=a

c

(4)

and we write

Lc

= Sc

+ iPc

. (5)

The penetration factor is Pc

= <Lc

and the shift factoris S

c

= =Lc

. Both take their names from their function

Resonances! Based on LRF=7 ! Flexible channel

specification ! All ENDF

approximations ! All ENDF

background correction schemes

! Common format

Specifications for particle properties

18

DRAFT

Requirements and specifications for a particle database

WPEC Subgroup 38

May 13, 2015

Contents

1 Introduction 3

2 Definitions 4

3 Requirements 5

3.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Specifications overview 8

5 Particle naming schemes 9

5.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Physical quantities and uncertainty 10

6.1 quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.2 uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.2.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.3 Particle property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.3.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 particleDatabase 14

7.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

8 documentation 16

8.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9 bibliography 16

1

Specification of low level data containers

20

⇤

⇤

Hopefully we’ve captured your input see https://www.oecd-nea.org/science/wpec/sg38/top_level_hierarchy.pdf

21

DRAFT

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 hierarchicalarrangement 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 legacyENDF format.

CONTENTS

I. Introduction 2A. Scope of data to support 3B. How to use these requirements 4C. Main requirements 4D. Hierarchal structures 5E. Complications 6

1. Is it a material property or a reaction property? 62. Di↵erent optimal representation in di↵erent

physical regions 73. Ensuring consistency 74. Legacy data 75. Special cases 8

II. Common motifs 8A. Documentation 8B. What data are derived from what other data? 11C. Product list elements 13D. <product> elements 13E. <distributions> and <distribution> elements 16F. Multiplicities 17

III. Particle and/or material properties database 18

IV. One evaluation 20A. Reaction designation 23B. The collection of reactions: <reactions> 24C. The <reaction> element 24D. Di↵erential cross sections: d�(E)/d⌦ and

d�(E)/d⌦dE 26E. Integral cross sections: �(E) 27F. Defining data styles 27G. Derived reactions 27H. Resonances 29

1. Designating channels 322. Resolved Resonances 343. Unresolved Resonances 364. Correcting cross sections and distributions with

background data 36

V. Grouping together evaluations 37A. Defining a collection of evaluations 37B. “E↵ective” or “Meta” evaluations 37

VI. Covariance data 41A. Covariance Definitions 41B. Covariance of continuous functions 43C. Covariance of multi-dimensional functions 44D. Covariance and correlation matrices 44E. Weighted sums of covariance 45F. The “Sandwich Formula” 46G. Monte Carlo Sampling 47

⇤Edited by D.A. Brown ([email protected])

H. Examples of covariance data usage in this hierarchy 48

VII. Required low-level containers 49A. The lowest-level 51B. General data containers 52C. Text 53D. Hyperlinks 53

VIII. Special reaction case: Atomic Scattering Data 54A. Incoherent Photon Scattering 55B. Coherent Photon Scattering 55

IX. Special reaction case: Particle production or Spallationreactions 56

X. Special reaction case: Radiative capture 56

XI. Special reaction case: Fission 57A. Introduction 57B. Existing ENDF format 58C. Fission format requirements 58

XII. Special component case: Fission Product Yields 59A. Introduction 59B. Existing ENDF format 59C. Detailed FPY format requirements for GND 60D. Discussion of possible implementations 61

XIII. Special reaction case: Large Angle Coulomb Scattering(LACS) 62

XIV. Special reaction case: Thermal Scattering Law 64A. Theoretical Background 64B. Gaussian approximation of the self part of the

scattering kernel 661. Coherent Elastic Scattering 672. Incoherent Elastic Scattering 683. Incoherent Inelastic Scattering in the Short

Collision Time Approximation 68

XV. Additional derived data elements for applications 68A. General Transport Data 69

1. Product average kinetic energy and forwardmomentum 69

2. µlab(E) 693. CDF’s from PDF’s 694. Probability tables in the URR 69

B. Grouped Transport Data 701. Inverse speed 712. Multiplicity 713. Q-value 714. Projectile kinetic energy and momentum 71

C. Production data 71D. Damage cross sections 72

XVI. Prototyping Functions 72

Acknowledgments 73

https://www.oecd-nea.org/science/wpec/sg38/top_level_hierarchy.pdf

overview of proposed new format, its similarities and ... · , and elements are used primarily to...

Documents