Reproduced
with permission from Geological and Nuclear Sciences Ltd, 31312,
Lower Hutt, New Zealand.
Nuclear
Sciences Group
Special note on data entry order :
The original
R33 specification called for data to be listed as x, y, xerrror,
yerror, however the R33 files originally generated for the
Sigmabase contained data entries in the order : x, xerror, y,
yerror. The original specification was intended to allow for
files containing no error information to be smaller, since the
two final entries could simply be omitted. However given that the
Sigmabase data fits easily on a single floppy, without
compression, the file size arguments are not compelling and
insisting on following the original specification will involve
disrupting several existing readers, as well as introducing
confusion through theexistence of two families of R33 files
since copies of the erroneous files will probably lie around for
years in different places. So, the new specification legalises
the previous erroneous usage.
(14 Apr 2004)
---------------------------------------------------------------------------------
The following changes in the list of legal entries are in force from March 7, 2006:
(updated)
Serial Number: [O] (0)
This field is no longer used and may be omitted from R33 files.
(New)
Subfile: [O] (' ')
When a new data file (usually of R33 format) is submitted for inclusion in IBANDL, it usually needs to be renamed and may require some modification of the included data. This field contains the name of the original data file submitted. Its use is reserved for the IAEA Nuclear Data Section.
(New)
X4Number: [O] (' ')
For R33 files that are derived from an entry in the EXFOR library of the IAEA, this entry provides a unique identifier for the original EXFOR dataset. It is composed of 17 characters, representing the EXFOR subentry number (8 characters), a space, and the date in the format YYYYMMDD. A valid record could be :
X4number: A1030002 20030227
Abstract
This report describes and ASCII data format for the communication
of Ion Beam Analysis (IBA) cross-section data. It is proposed
that the IBA community adopt this format to simplify setting up
an IBA cross-section database at a later date.
Keywords Nuclear
cross sections; ion beams; computers; data storage; data
transmission
Introduction
At the Third International Conference
on Chemical Analysis, (Namur, July 8-12 1991) a workshop was held
on the establishment of a database of cross-section data of
interest to the IBA community and a summary of the discussions is
likely to be published in the proceedings [1]. Although no firm
followup action (apart from writing the report [1]) was proposed
at the workshop, the general utility of such a database was
widely endorsed, and a consensus was arrived at for a number of
issues. As an interim measure until a centralised database is set
up, it is proposed that the IBA community adopt a standardised
way of transmitting measured cross-section data. This report
proposes such a standard.
Scope
This standard is intended to apply to
charged incident particle prompt IBA cross-sections giving rise
to nuclear interactions (i.e. excluding PIXE, but including
PIGME) in the energy range from 0 to say 50MeV. Although the
detection of neutrons as products of nuclear reactions is
included, the use of incident neutron beams for prompt NRA is not
included for the time being. The file format is intended to be
sufficiently flexible that these cross sections may be tabulated
if the need arises. This statement of scope is not intended to be
definitive - the scope of the database to be set up will be
decided by the operating organisation. For example the 50MeV
limit would not exclude tabulations of the cross-sections of
reactions of interest for hydrogen depth profiling in the
laboratory frame in which hydrogen is the stationary target,
however it is not suggested that all of the (d,p) cross-sections
need to be measured up to 50MeV for IBA!
The special case of resonant nuclear
reactions may need specification of further fields, but at
present they may be accomodated as experimentally measured thin
target excitation curves and prospective authors may be invited
to include as much information as possible about target
thickness, uniformity etc, and deduced resonance parameters in
the COMMENT field of the proposed file format. The total number
of resonances of interest to the IBA community is not likely to
be more than a few hundred, and inclusion of this data either as
a special subsidiary database or as special records in the main
cross-section database should not be of great technical
difficulty.
The choice of ASCII
Whilst it is recognised that ASCII
representation will take up a lot more space than binary
representation, the transportability of ASCII between virtually
all computing platforms probably far outweighs the space
disadvantage. Furthermore ASCII files are readily transmittable
via even very rudimentary E-mail systems, and communications
programs. Local binary formats, for example for use in RUMP [2]
or SENRAS [3], or for producing local hardcopy (e.g. with GENPLOT
[4] ) of cross-sections of interest, will undoubtedly be adopted
at each site.
Nevertheless, the ASCII format has
been designed in such a way that inclusion into PC based
databases or spreadsheets should be relatively straightforward.
In the event that a centralised database is set up, collection,
collation and archival of the data will be very much easier for
data that is already in a standard format. The format has also
been designed to be flexible, especially with respect to the
addition of further fields.
Inclusion of errors/absolute versus
relative cross-sections.
As far as tabulation of cross-section
data is concerned these two issues are intimately related. We
assume that the tabulated cross-sections and energies are
estimates of the physical value they represent. The tabulated
errors (where present) are estimates of the standard deviation of
the spread in values if the measurement of that energy or
cross-section were repeated under identical experimental
conditions. These estimates reflect the precision, or
repeatability, of individual data values.
Normally the physical value sought
(cross section or energy) is inferred from the actual value
measured in an experiment (e.g number of counts, or NMR probe
magnetic field value) by application of knowledge of the
experimental parameters (e.g. solid angle and detector
efficiency, or ion mass, charge state, and trajectory radius in
the analysing magnet). These experimental parameters are also
imperfectly known, although in well designed experiments there
should not be significant random fluctuations in their values!
They may be assumed to be the same for all the data values in a
given experimental run, and often vary insignificantly between
experimental runs. We assume a simple linear relationship between
the measured parameter and the inferred physical quantity. This
is a simplification, since systematic errors may change in a
non-random way during an experiment - temperature dependence of
gains in electronic equipment; target instability under the beam;
and so on. However we assume that a good experimenter keeps these
effects much smaller than the random errors associated with each
data point. The uncertainty in our knowledge of the constant
relating the physical quantity to the measured quantity is a
measure of the systematic error in the experiment. The smaller
this uncertainty the greater the accuracy of the measurement.
Assume that the tabulated
cross-section values are called Tsk
(indexed from k=1 to k=NVALUES) and the corresponding real
absolute cross-section values Sk. Then we define Fs
by
Sk
= Fs Tsk
for each value of k.
The conversion factor Fs
and its associated error dFs are included in the file
as a field. Now it is clear that if Fs=1, then the
tabulated values are simply the absolute cross section. However
if the tabulated data are numbers of counts or some other units
then Fs converts the tabulated data into absolute
cross-sections. By definition values of Fs and dFs=0
are taken to mean that the conversion factor and absolute
accuracy respectively are unknown.
Similar considerations will apply to
the energy values for each data point, with an additional
possibility of a shift error in the energy scale. Assume that the
tabulated energy values are TEk and
that the real corresponding energy values are Ek. Then
the factors F0E, F1E, and the associated
errors dF0E and dF1E are defined by:
Ek=F0E
TEk + F1E.
Obviously, although F0E is
dimensionless, F1E has the same dimensions as the TEk.
These will be keV.
The 'random' errors may be listed
after each data point in the file. The error values will be
understood to mean that the author estimates that there is a
68.2% probability that the average value of an infinite number of
measurements would lie between the tabulated value plus the
tabulated error and the tabulated value minus the tabulated
error. This means that if the random errors in the data follow a
normal distribution the tabulated error is just the standard
deviation. For normal counting statistics in which more than
about 10 counts are recorded, the tabulated error would then just
be the square root of the number of counts (multiplied by
whatever factor was necessary to convert the counts into the
tabulated units). If these error values are not given or are set
to zero, then it is assumed that no estimate of the data
precision has been furnished by the author. At the moment no
provision is made for asymmetrical error estimates.
The ASCII file format:
COMMENT:
Arbitrary length, may contain embedded spaces, tabs, carriage
returns (CR), linefeeds (LF). Must contain at least 1 CRLF
sequence every 80 characters.
Contains comments on the reliability of the data, the
experimental arrangement, target thickness etc. Would also
normally include the publication details if the data has been
published, or an indication of how the author wishes to be cited
in work which makes use of this data. (e.g. "please cite
A.G. Physicist, pers. comm." or "please cite Another
Physicist (2015), IBA Data Archives vol 1 (1) pp.107-118".
The authour may also include here any details of semi-empirical
fits that he or she may propose for the data - equations, and
values of coefficients. Comment ends with "CR LF CR LF"
i.e. a blank line.
NAME:
ADDRESS1:
ADDRESS2:
ADDRESS3:
ADDRESS4:
ADDRESS5:
ADDRESS6:
SERIAL NUMBER:
REACTION:
DISTRIBUTION:
MASSES:
QVALUE:
THETA:
SIGMA FACTORS:
ENERGY FACTORS:
NVALUES:
energy, sigma,
energy error, sigma error, CR LF
energy, sigma,
energy error, sigma error, CR LF
(continue until
NVALS values is reached)
Example
COMMENT: A. Good
Physicist. Institute for Fantastic Physics, 200 Nevernever
street, Richton, Peoples Democratic Kingdom of Nirvana. Telephone
(+123) 456789, fax 987654, E-mail AGP@FANPHYS.NIRVANA. This data
is completely bogus. It was measured by a totally thick student
and I've only sent it to the database so that some poor soul can
try to evaluate it because I couldn't.
NAME: Physicist,
A. G.
ADDRESS1: Inst.
for Fantastic Physics,
ADDRESS2: 200
Nevernever street,
ADDRESS3: Richton
75005,
ADDRESS4:
People's Democratic Kingdom of Nirvana.
ADDRESS5:
ADDRESS6:
SERIAL NUMBER:
123456
REACTION:
2H(d,t)p
DISTRIBUTION:
Energy
MASSES: 2, 2, 3,
1
QVALUE: 8956
THETA: 35
SIGFACTORS: 1.0
0.0
ENFACTORS: 1.0,
0.0, 0.0, 0.0
NVALUES: 10
100
7.334e-1 .1
.03e-14
200
7.334e-1 .1
.03e-14
300
7.334e-1 .1
.03e-14
400
7.334e-1 .1
.03e-14
500
7.334e-1 .1
.03e-14
600
7.334e-1 .1
.03e-14
700
7.334e-1 .1
.03e-14
800
7.334e-1 .1
.03e-14
900
7.334e-1 .1
.03e-14
1000
7.334e-1 .1
.03e-14
Notes:
1) The ASCII file
is broken up into fields.
2) Each field
ends with a CR LF (Hexadecimal Od OA), except for the special
case COMMENT field, which ends with CR LF CR LF (which means a
blank line when the file is printed out). The comment field is
the first field.
3) No field
except the COMMENT field is longer than 80 characters (excluding
the CR and LF characters but including the comment name and
colon). The reason for this (and also for the CR LF every 80
or less characters in the comment) is so that the cross section
file may be readily printed out in simple ASCII to any device
that can print up to 80 characters on one line. There is no limit
on the length of the comment, which may contain any of the ASCII
character set (up to Hexadecimal FF) in any order, except the
double CR LF sequence anywhere other than at the end i.e. it may
not contain blank lines). The comment is preferably to be in
English.
4) Each field
except the data begins with its name, in capitals, followed
immediately by a colon and a space (HEX 20).
5) The serial
number is at present irrelevant, but would be assigned by a
hypothetical database management organisation.
A double standard is proposed for the
specification of nuclear reaction species. The most robust would
be the complete chemical symbol to denote the atomic number, with
the mass number prefixed (e.g. an alpha particle would be 4HE,
and RBS on Si would be 28SI(4HE,4HE)28SI), and suffixed particle
group numbers (e.g. 16O(2H,1H0)17O and 16O(2H,1H1)17O for 16O(d,p0)
and 16O(d,p1) respectively. Neutrons would
be 1N. Gamma rays would be represented by G or g, and X-rays
(although it is not at present intended to include PIXE data in
the cross-section data-base) by X or x. An optional notation is
to use lowercase letters to specify the various light projectiles
and products that are features of IBA:
p for proton
d for deuteron
t for triton
a for alpha
g for gamma
x for X-ray
n for neutron
A fairly free numerical format is
suggested for the data values. Valid separators would include
space, comma, semicolon, colon, and tab. The numeric data may be
specified using exponential notation (e.g. 1000 could 0.1e4, or
1e3, or 10e2) or simple decimal notation (1000, 1000.0 etc) to an
arbitrary number of digits. 7 digits is suggested as a reasonable
maximum.
Units
All quantities are referred to the
laboratory frame of reference. Energies will be specified in keV,
angles in degrees, and absolute differential cross-sections in
mb/sr. If cross-sections are specified in other units (e.g counts
per uC per mg/cm2) then this should be clearly stated
in the COMMENT field, and Fs set to the appropriate
value.
References
1) I.C.
Vickridge. Nucl. Instr. and Meth B66, (1992) 303-305.
2) RUMP User's
Manual. CGS Computer Graphics Services, 52 Genung Circle, Ithaca
NY 14850-8716, United States of America
3) G. Vizkelethy.
'Simulation and Evaluation of Nuclear Reaction Spectra'. Nucl.
Instr. and Meth B45, 1 (1990)
4) GENPLOT User's
Manual. CGS Computer Graphics Services, 52 Genung Circle, Ithaca
NY 14850-8716, United States of America
Update
to the R33 cross section file format
A
report tabled at the XXX meeting, Obninsk, May 2000
By
I. C. Vickridge
Groupe
de Physique des Solides, UMR 7588 du CNRS
Tour
23, Universités de Paris 7 et 6
2,
Place Jussieu
75251
Paris
Introduction
In September
1991, in response to the workshop on cross sections for Ion Beam
Analysis (IBA) held in Namur (July 1991, Nuclear Instruments
and Methods B66(1992)), a simple ascii format was proposed to
facilitate transfer and collation of nuclear reaction cross
section data for Ion Beam Analysis (IBA) and especially for
Nuclear Reaction Analysis (NRA). Although intended only as a
discussion document, the ascii format - referred to as the R33
(Report 33) format - has become a de facto standard. In the
decade since this first proposal there have been spectacular
advances in computing power and in software usability, however
the cross-platform compatibility of the ascii character set has
ensured that the need for an ascii format remains.
Nuclear reaction
cross section data for Nuclear Reaction analysis has been
collected and archived on the Sigmabase website (give Vizkel and
Battistig www sites) for about the last 7 years. This data has
largely been entered in the R33 format, although there is a
series of elastic cross sections that are expressed as the ratio
to the corresponding Rutherford cross sections that have been
entered in a proprietary format referred to as RTR (ratio to
Rutherford). During this time the R33 has been modified and added
to - firstly to take into account angular distributions, which
were not catered for in the first proposal, and more recently to
cater for elastic cross sections expressed as the
ratio-to-Rutherford, which it is useful to have for some elastic
scattering programs. It is thus timely to formally update the R33
format
There exists also
the large nuclear cross section data collections of the Nuclear
Data Network -the OECD NEA Nuclear data section, the IEAE Nuclear
data XXX, the Brookhaven National Laboratory National Nuclear
Data Centre amongst others. In the past, much of the data
routinely used in Nuclear Reaction Analysis was not available
from the NDN sites, which were originally set up for a different
purpose. Recently, an increasing amount of experimental data that
is useful for the NRA community has been being added to the Exfor
database, and this is likely to continue. There is a proposal to
provide a facility that will automatically download cross
sections from a projectile/target/energy/angle range appropriate
for NRA to the sigmabase servers. The R33 format is proposed to
become a legal computational format for the NDN, and the data
downloaded to the sigmabase servers will be in R33. It is thus
also necessary to provide an updated formal definition of the R33
format in order to provide the necessary specification for
adoption of R33 as an accepted computational format.
Guiding
considerations.
In defining the
updated R33 format I have required that previous valid R33 files
should also conform to the updated format. This is so that R33
reading programs that conform to the updated specification will
be able to read the existing R33 files - this is a way of
providing backward compatibility via the file format rather than
requiring it of the reading routines. Furthermore, there is some
redundancy in the format. This is partly from intellectual
laziness, but also provides some checking of internal consistency
to weed out errors.
The new R33
Format definition.
An R33 data file
contains one cross section either as a function of (laboratory)
incident energy, or as a function of (laboratory) detection
angle. The file is made up of entries, and the data section. Each
entry consists of a legal keyword followed by a colon followed by
a space, followed by data in Ascii format. The keyword may be in
any mixture of upper and lower case characters. Legal separators
for numerical data are space, comma, colon, and semi-colon
characters. Decimal points are represented only by full stops,
and not by commas (as can be the case in some European
countries). The legal ascii character set for the purposes of R33
files is ascii 0 to ascii FF. Apart from the 'Comment' entry and
the optional 'Version' entry, entries may be in any order. Each
entry ends with a carriage-return line-feed sequence. Some
entries are optional [O], most are required [R], and some
are mutually exclusive [Mx] where all entries for which the value
of x is the same are mutually exclusive. See below for special
conditions that apply to the keywords 'Comment', 'Nvalues', and
'Data', and 'EndData'. The default values are given for R33
reading routines, so that if an optional entry is omitted, or if
a required entry is unreadable or missing illegally, the value of
the corresponding variable in the reader is well-defined. All
energies are expressed for the laboratory frame in keV and all
angles in the laboratory frame in degrees.
Legal entries in
R33 files
Syntax
The syntax for
the list of legal keywords and the associated data is :
Keyword:
[Mx, O/R] (Default) <data type>
Note:
Additional notes and guidelines concerning use of the entry. Data
type may be:
string
(an arbitrary series of ascii characters)
n
(integer) a series of ascii characters without decimal point
representing a signed integer number
r
(real) a series of ascii characters that represent a signed real
number. Format is fairly open - but only decimal points (and NOT
decimal commas) are accepted. ICV needs to specify this a little
more tightly yet …
List of legal
entries
Comment:
[R] ('None') <String>
Note:
An unlimited number of ascii characters, including single CR LF
sequences, but terminating by a double CR LF sequence. There is
no requirement to embed CR LF sequences within the Comment,
however it is recommended to place CR LF sequences at convenient
places at least every 80 characters so that if the file is
printed, the comment field is printed on successive lines that
are not longer than 80 characters. The double CR LF sequence that
signals the end of the comment is simply a blank line. It is not
felt necessary to specify an upper limit to the size of the
comment, however it is expected that a useful comment would not
be longer than a few tens of lines - or a few thousand
characters. Note that unix systems place only a LF character to
signal an end-of-line. This is illegal for R33 files. There
are freeware and shareware utilities that can add the necessary
CR characters if R33 files are generated on Unix boxes.
Version:
[O] ('DSIR R33') <String>
Note:
Allowed values are (case-insensitive) 'DSIR R33' and DSIR R33a'.
This entry can be used to signal that the file conforms to the
special subset of R33 files proposed by M. O. Thompson for
elastic scattering cross sections for use in RUMP. Sigmabase
files will always be DSIR R33, but the 'R33a' variant is detailed
here for completeness. All R33a files are legal R33 files, but
R33a files have the following additional conditions:
1)
The Version entry is required, and must be the first entry after
the Comment.
2)
Only elastic cross sections can be in valid R33a files
3)
Nvalues must either not be present, or have a value of
less-than-or-equal-to zero.
Source:
[R]('Unknown')<String>
Note:
A concise bibliographic source (preferable) or another indication
of where the data has come from (avoid if possible). This
field should contain the most authoritative original source for
the data. This will usually be the original publication, or
thesis reference. In some cases data has been input by
experimenters before or without publication. In this case this
entry should contain something like 'Measured and input by D.
Withrington'. It should be kept small - an upper limit of 256
characters is suggested, but not required. It would be expected
that further details pertaining to Mrs Withrington would be found
in the Comment.
Name:
[R]('unknown')<String>
Note:
The name of person or institution responsible for creating the
R33 file. For R33 files automatically created from Exfor files,
this would be IAEA, or NNDC, or Interational Nuclear Data Network
or whatever. No provision is made here for including update
histories, however this may be accommodated in the Comment field.
Address1:
[O] (' ') <String>
…
Address9:
[O] (' ') <String>
Note:
The address of the person or institution responsible for creating
the R33 file. Up to nine lines of address information may be
included. This can include telephone numbers, emails and so on.
Serial Number:
[R] (0) <n>
Note:
The serial number will be a number providing a unique link back
to the Exfor dataset from which the R33 file was generated. The
default value of zero means that this number has not been
assigned.
Reaction:
[R] (' ') <String>
Note:
the reaction string is written in a standard format that can be
parsed without too much difficulty. It conforms to the usual
notation of:
target
nucleus(incident ion, light product)product nucleus
Nuclei
are specified by their chemical symbol preceded by A : eg 28Si,
or 6Li. Some common light species may also be represented by
shorthand notation
n=neutron
p=proton
d=deuterium
t=triton
a=alpha
particle
h=3He
x=x-ray
g=gamma
The
light product may correspond to a particular energy level of the
compound or product nucleus. This is signalled by a 'postfix' on
the light product. For example, 16O(d,p1)17O is the (d,p)
reaction which leaves the residual 17 oxygen in the 1st
excited state. Some cross sections may be sums of several
particle groups corresponding to different excited states of the
compound or product nucleus. Usually such a cross section would
be used when the particle groups are not resolved by the
detection method employed. In this case, the postfix lists the
states concerned, separated by plus signs. E.g. 14N(d,p5+6)15N.
Some elastic cross sections correspond to targets having several
isotopes. In this case, it is necessary to use the 'target'
keyword.
Masses:
[R] (1,1,1,1)] <n,n,n,n>
Note:
Four values of A corresponding to the four nuclei specified in
the reaction string, separated by legal separators. In principle
the masses could be deduced directly from the reaction string,
however in the interests of simplicity it seems worthwhile adding
them to the R33 file to avoid having to write a reaction string
parser in R33 readers.
Zeds: [R]
(1,1,1,1) <n,n,n,n>
Note:
Four integers representing the atomic number of the four nuclei
specified in the reaction string. The Zs could also be deduced
directly from the reaction string, but see the comment in the
Masses entry.
Target:
[O] (''Natural') <string, r, string, r, …>
Note:
This entry caters for elastic cross sections measured from
targets that contain a mixture of isotopes from which the
elastically particles are not resolved. It consists of a list of
isotopes and atom-proportions, or the value 'natural' (case
insensitive) which means that a target of naturally occurring
isotopic composition has been used. Isotopes are specified as for
the reaction string, without shorthand notation. Example :
Target:
12C, 23.0, 13C, 26.0
If
the proportions do not sum to 100, then it is assumed that they
are relative amounts. In the example given, 23/49 of the atoms
are 12C, and 26/49 are 13C.
Qvalue:
[R] (0.0) <r, r, r, r, r>
Note:
A list of up to five Q values, expressed in keV, separated by
legal separators. As explained in the Reaction entry, some cross
sections are for multiple particle groups, for example when the
groups are not resolved experimentally. In this case a Q value is
required for each particle contributing to the cross section.
Distribution:
[R] ('Energy') <String>
Note:
Allowed values are 'Energy', 'Angle' or 'Total'. This entry
says whether the data contained in this file are for a
cross-section differential with laboratory energy ('Energy') or
differential with laboratory angle ('Angle'). The value 'Total'
signals that the cross section is integrated over all detection
angles. Values are case insensitive.
Theta:
[M1, R] (0.0) <r>
Energy:
[M1,R] (1.0) <r>
Note:
Theta gives the laboratory angle with respect to the incident
beam, so that backscattering would be 180°. Energy gives the
laboratory energy of the incident beam. If both entries are
present (an illegal condition …) then only the entry
corresponding to the keyword in the 'Distribution' entry will be
used. If there is no 'Distribution' keyword AND valid theta and
energy entries exist (a doubly illegal condition …), then it
is assumed that the data in the file are differential with
respect to energy. If there is no 'distribution' keyword, and no
theta or energy keyword (another doubly illegal condition) then
it is impossible for even the best-intentioned reader to deduce
what the data refer to, and the file is invalid.
Sigfactors:
[O] (1.0, 0.0) <r,r>
Note:
Scale conversion factor and its associated error common to all
the cross section data. See original R33 publication in Appendix
1 for discussion.
Units: [O]
('mb') <String>
Note:
Valid values are 'mb' and 'rr'. R33 files are always in mb/sr, or
units proportional to mb/sr for differential cross sections, and
mb for total cross sections. The constant of proportionality
given in the enfactors entry is independent of energy. Some users
find it preferable to have elastic scattering cross sections
relative to the Rutherford cross section. Since the conversion
factor is no longer energy-independent, the enfactors entry can
longer cater for this. In this case, the units entry should
specify 'rr' for ratio to Rutherford. Nevertheless, it is
recommended that elastic cross sections be stored as cross
sections just like the inelastic scattering cross sections - i.e.
in mb/sr.
Enfactors:
[O] (1.0, 0.0, 0.0, 0.0) <r,r,r,r>
Note:
Scale conversion factors and associated errors common to all the
energy or angle data. See original R33 publication in Appendix 1
for discussion.
Nvalues:
[M2,R] (0)<n>
Data:
[M2,R]
Enddata:
[O]
Note:
two methods are allowed for representing the data. The first
corresponds to the original R33 specification. The data
immediately follow the 'Nvalues' entry consists of the cross
section data, one point per line, and each point represented by
four values (X, dX, Y, dY):
energy(or
angle), energy(or angle) random error, sigma, sigma random error
The
data ends after Nvalues lines of data, and any subsequent lines
are ignored.
Alternatively
(and recommended), the data may be bracketed by 'Data' and
'Enddata' entries. An entry of 'Nvalues: 0' is equivalent to a
'Data' entry. The data immediately follow the Data entry, one
point per line as for the Nvalues option, and the file terminates
with the end of the file, or with the optional EndData entry.
Nvalues is maintained for backward compatibility, but in practice
most routines will simply read and count the number of lines read
until the end of the file or an EndData entry is reached, so this
is the preferred option.
Data
entries must be arranged in order of increasing energy or angle.
Duplicate energy or angle values are not allowed (the cross
section must be single-valued).