next up previous contents
Next: Scan date vs observation Up: Memory index Previous: Strategy   Contents

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 up previous contents
Next: Scan date vs observation Up: Memory index Previous: Strategy   Contents
Gildas manager 2023-06-01