# 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.