XAFS data can be stored efficiently and conveniently in the UWXAFS binary format. These files use less disk space than ASCII data files. Since they cannot be easily edited, accidentally deleting some of the data in a UWXAFS binary file is essentially impossible. But the biggest advantage over ASCII data files is that more than one set of data can be held in a single data file, making organization of data easier for the UWXAFS binary files.
The drawbacks to the UWXAFS binary files are that they cannot be transported between machines (unless both the architecture and operating system are the same) and that special routines must be used every time data is to be accessed. This second point means that general-purpose programs will be unable to handle data in the UWXAFS binary format.
The UWXAFS file handling system allows a single binary file to store
several data sets in different "records". Each file has a file type
associated with it that determines the format of the data held in the file.
Different file types cannot be mixed in a single file. Usually the file
type will also be the extension of the file name. This is not required
(and is violated by
nkey, which is the "address"
for this record in the data file. This is independent of the content
of the record, and depends only on the location in the file.
skey, which is a unique "address"
for the data in a record no matter where in the data file it is, or
even which data file its in. If the data in one record is copied to
another file, the skey will move with the data, whereas the
nkey can change.
The data from a record in a UWXAFS binary file can be retrieved by specifying the file name and either the NKEY or SKEY of the record.
Each of the file type stores numerical data in a different way. Usually
you don't need to worry about this. But if you're using bkg have file
type xmu), there should not be any problems. The following sections
describe how each of the file types stores the numerical data. Each stores
a single buffer of real numbers, which I'll call Buff, which has
N_buff elements.
Files with xmu File Type contain absorption data on an energy
grid which does not need to be evenly spaced. The units of energy are
eV. This file type is used for raw absorption data input to xmu
format before being used in
Files with chi File Type contain chi(k) data. The data is
evenly k-space, and this is exploited in the storage of the
data. The first element of Buff is k_min, the lowest value
for which chi(k) is stored (in inverse Angstroms). The second
element of Buff is delta k, (also in inverse Angstroms), which
will normally be 0.05. The remaining N_buff - 2 elements
of Buff contain the elements chi(k) themselves.
Files with rsp File Type contain chi(R) data. The data is
evenly R-space, and this is exploited in the storage of the
data. The first element of Buff is R_min, the lowest value
for which chi(R) is stored (in Angstroms). The second element of
Buff is delta R, (also in Angstroms), which will typically be
about 0.031. The remaining N_buff - 2 elements of Buff
contain the complex elements chi(R) themselves, stored in successive
pairs of real and imaginary parts of chi(R).
Files with env File Type contain backtransformed EXAFS data
(chi(q)). The data is evenly k-space, and this is exploited
in the storage of the data. The first element of Buff is
k_min, the lowest value for which chi(q) is stored
(in inverse Angstroms). The second element of Buff is delta k,
(also in inverse Angstroms), which will normally be 0.05. The
remaining N_buff - 2 elements of Buff contain the complex
elements chi(q) themselves, stored in successive pairs of amplitude
and phases of chi(q).