Next: Scan date vs observation
Up: Memory index
Previous: Strategy
Contents
When the index file is loaded, its index content is duplicated in
memory for all the entries. These elements are described in the
Table 1.
Table 1:
Memory index elements coming directly from the index file.
Parameter |
Unit |
Comment |
bloc |
records |
Entry position in index file |
word |
words |
Entry position its this record |
version |
-- |
Entry version |
telescope |
code |
Telescope code |
projid |
-- |
Project id |
source |
-- |
Source name |
dobs |
gag_date |
Observation date |
ut |
rad |
Observation time |
lst |
sec |
Local Sideral Time |
az |
rad |
Azimuth |
el |
rad |
Elevation |
frontend |
-- |
Receiver names |
scan |
-- |
Scan number |
backend |
code |
Backend code |
obstype |
code |
Observation type |
switchmode |
code |
Switching mode |
filstatus |
code |
Can read file or not? |
calstatus |
code |
Calibration status |
filename |
-- |
IMB-FITS file (no path) |
itime |
nanosec |
Last indexing time (from 01-jan-1970) |
Table 2:
Memory-only index elements associated to each entry
Parameter |
Unit |
Comment |
num |
-- |
Observation number |
mnum |
-- |
Entry position in the Input indeX (IX) |
fnum |
-- |
Entry position in the index file |
idir |
code |
Associated index file and IMB-FITS directory |
sort |
-- |
Sorting array |
However, these elements alone are not enough to deal with each
IMB-FITS file referenced in the index. Extra numbers are associated
on-the-fly, at load time. The Table 2 summarizes those
numbers. In details, here is the exact meaning of those numbers:
- num: the observation number is a unique number
associated to each IMB-FITS file. Uniqueness is ensured by a unique
combination of the observing date, the scan number, and the
backend. In a memory index, there can be several version of
the same observation, meaning that the same IMB-FITS file is indexed
several times (e.g. a first time when the index is built, a second
time after the calibration). This number (and optionaly its version)
is intended to be used as a frontend to the end-user. However, it is
volatile: it can change from one session (or one INDEX OPEN) to
another, depending on the index contents, and their number and order
if several indexes are loaded in memory. In practice, the
observation numbers are contiguous, starting from 1, and ordered by
observing date, then by scan number, then by backend code.
- mnum: the memory number is the entry position in
the input index (IX), and thus it provides a unique identifier for
each entry indexed in memory. This means that the array ix%mnum(:) runs contiguously from 1. Since IX is the absolute
reference for all sub-indexes (e.g. the current index CX), each
entry of any index can easily be identified thanks to this back
pointer (e.g. cx%mnum(ient)).
- fnum: the file number is the entry position in its
associated index file. This number can not be implicit, because
several index files can be loaded in memory, and because the entries
are reordered by date, scan and backend at load time.
- idir: the directory code identifies each index file
loaded in memory, so that each entry knows easily to which index
file it comes from. This code also identifies the directory the
IMB-FITS can be found in (remember the index file may not be hosted
in the same directory; this is controled by the user through the
command INDEX /FILE).
- sort: the sorting array is an indirection array
which would order the memory index by date, by scan, and by
backend. At load time, the entries are actually ordered in memory,
so this array is not needed at this time. But later on, commands
like CALIBRATE or PIPELINE can add new versions of the
entries. These new entries are appended at the end of the memory
indexes, in order to avoid breaking the cross references between
indexes (in particular, the cx%mnum(:) back pointers to
IX). Each application which needs to access the entries sorted by
date, scan, and backend, should then use the sorting
array. Typically, one has to loop on cx%mnum(cx%sort(ient))
(with ient 1 to cx%next-1) to access the entries
ordered correctly.
Next: Scan date vs observation
Up: Memory index
Previous: Strategy
Contents
Gildas manager
2014-07-01