3.3 XAS files


We give here an user's overview of XAS data files, while programming details will be given elsewhere.

Overview

There are the following basic kind of files used by XAS :

XAS data files

XAS data files are binary files using native internal representation of the specific operating system, and using a mission-independent format. All families of XAS files, listed below, share a common organization consisting of : The following are the types of XAS files :

Where do XAS data files reside ?

XAS uses its own system-independent file naming convention (VOS names), which is translated into system dependent names by appropriate routines. This is in practice not a concern for the general user, and in particular for the Unix user, since VOS names virtually (sic!) coincide with Unix names. A name may be of the form :
/dir/dir/.../name.type
dir/dir/.../name.type
name.type
name
The type (usually one of the standard ones given above) is often omitted and assigned automatically by the programs, or by context.

Also the path (either absolute or relative) is usually omitted, and is instead built by programs.

It is important to remember that, irrespective of what is the current working directory, XAS programs will look for files (without an absolute path) or create them in specific directories previously decided by the user, and namely

Relative paths are relative to this particular directory !

The full path of each of these directories is constructed on the basis of several environment variables, in order to allow each user the maximum flexibility. We give here examples for the "data directory", while the cases of the "FOT" and "print" directory are similar, replacing fotdir or printdir to datadir, and optionally replacing fotorder or printorder to order (if this is not done one obtains the same hierarchy).

The full path for the "data directory" is constructed of up to 5 parts (each part being in turn a path), e.g.

/part1/part2/part3/part4/part5
part1 is always a logical root, the value of rootdir
The other four parts (of which three can be omitted) are controlled by the four variables datadir, target, date, instrument, and occur in the order specified by variable order

Compare the following examples :

Flat arrangement

xasset rootdir /home/me
xasset datadir mydata
Default order assumed, data files are in /home/me/mydata

Complex arrangement

xasset rootdir /home/me
xasset datadir mydata
xasset target Crab
xasset date Sep06
xasset instrument mecs
xasset order ctdi
Data files are in /home/me/mydata/Crab/Sep06/mecs

Changing order

If one instead does e.g. xasset order cidt data files go in /home/me/mydata/mecs/Sep06/Crab
All permutations are possible.

One can also omit a part, e.g. if one does xasset order cd data files go in /home/me/mydata/Sep06
If one xasunset order the default path /home/me/mydata is restored.


Using different orders

Let us assume that one wants to do a standard reduction for a particular object, or observation, or dataset called pinco, then the same reduction for another dataset called panco and finally combine the results :
xasset rootdir /home/me
xasset datadir mydata
xasset target pinco
xasset order ct
Files for first data set are created as /home/me/mydata/pinco/name.type
xasset target panco
Files for other data set are created as /home/me/mydata/panco/name.type
xasunset order
The system will look for data files in /home/me/mydata, therefore one may refer to the files of either data sets with relative paths like pinco/name.type or panco/name.type and call merged files just as name.type. The same result will occur doing xasunset target

[Previous][Next] [Up][Down]