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
.
Table:
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 |
-- |
IMBFITS file (no path) |
itime |
nanosec |
Last indexing time (from 01-jan-1970) |
Table:
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 IMBFITS directory |
sort |
-- |
Sorting array |
However, these elements alone are not enough to deal with each IMBFITS
file referenced in the index. Extra numbers are associated on-the-fly, at
load time. The Table
summarizes those numbers. In details,
here is the exact meaning of those numbers.
- num
- The observation number is a unique number
associated to each IMBFITS 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 IMBFITS 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 IMBFITS 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
2023-06-01