Vous êtes ici : Accueil / TECHNICAL PAGES / Documentation / Logiciel d'observation / Administration T4 / Gestion des descripteurs FITS

Gestion des descripteurs FITS



Les headers des fichiers FITS fabriqué par notre logiciel d'observation sont composés des descripteurs décrits dans des fichiers squelette d'extension .ske (skeleton).

Fabriquer un header consiste à envoyer à chaque Inter du logiciel d'observation une requête afin que chacun participe à remplir le header d'un fichier temporaire avec les descripteurs sous sa responsabilité selon les informations contenues dans le fichier squelette.

Après cela et au moment de l'archivage par l'inter contrôlant le CCD, cet Inter complète le header standard Fits avec ses propres descripteurs (décrits également dans un fichier squelette) et complète le tout avec le header du fichier temporaire. Ainsi le fichier est complet à ce moment.

Le contenu typique d'un fichier squelette ressemble à cela:

INSTRUME= 'CORALIE'    / Nom de l'instrument
CRVAL1  = 9999.999     / crval1 / world coord at reference pixel
HIERARCH ESO CORA CCD BINX =  9999.999 / e.binx / Binning X CCD
HIERARCH ESO CORA CCD ROTYPE = '9999.999' / e.ccdros / Mode lecture CCD

On remarque avant le symbole égal ("=") le nom du descripteur, suivit de la valeur, puis après le slash ("/") les commentaires. Attention, seuls les 80 premiers caractères sont pris en compte. Attention également, selon le formatage de la valeur, le commentaire est décalé vers la droite et donc peut être tronqué.

Dans le cas d'une constante (exemple: 'CORALIE') cette valeur est simplement écrite.

Dans cas de variables, on renseigne le nom de la variable Inter qui sera écrite dans la partie commentaire du descripteur, entre 2 slash ("/"), exemple: e.binx.

Il est clair que la variable Inter doit être définie pour l'Inter concerné et bien sur à jour pour ce dernier. Par exemple on ne peut pas demander à l'Inter-t120 de renseigner sur le binning du CCD, car uniquement l'Inter-Ecam peut le faire.

 



Organisation dans le File-System

Les fichiers squelettes sont sous

$THOME/config/ske_fits

Sous ce directory on trouve 2 types de directories, ceux dédiés aux informations génériques et ceux dédiés aux applications.

Les génériques:

generic_ccd/ generic_pisco/ generic_spectro/ generic_synchro/ generic_tele/

Ceux des applications (lien liens ont un "@"):

bigeye@ coralie/ euler/	guidage/ iecam@	pisco/ spectro@ t120@
cora/ ecam/ icora@ ipisco@ rfi/	synchro/

Ces applications correspondent aux nom des Inters connus du logiciel d'observation. On utilise des liens pour les applications identiques, exemple:

guidage/
bigeye -> guidage/
cora/
icora -> cora/
coralie/
spectro -> coralie/
ecam/
iecam -> ecam/
euler/
t120 -> euler/
pisco/
ipisco -> pisco/
rfi/
synchro/

Il n'y a aucun fichier squelette dans les directories dédiés aux applications. Il n'y a que des liens vers des fichiers squelettes génériques.

Tout les fichiers à modifier sont dans les directories dédiés aux génériques, exemple:

generic_ccd:
astromed_descripteurs.ske  coralie_descripteurs.ske  ucsd_cora_descripteurs.ske
bigeye_descripteurs.ske    ecam_descripteurs.ske     ucsd_ecam_descripteurs.ske

generic_pisco:
descripteurs.ske

generic_spectro:
descripteurs.ske

generic_synchro:
coralie_descripteurs.ske  ecam_descripteurs.ske

generic_tele:
coralie_descripteurs.ske  ecam_descripteurs.ske

Le principe de base de l'utilisation des fichiers squelettes est, pour une application donnée, d'utiliser au travers de code dans les procédures (voir les appels à la procédure archive_applic_descripteurs.prc) les fichiers contenus dans le directory de l'application. Un exemple pour ecam:

# ls -l ecam
 ecam_descripteurs.ske    -> ../generic_ccd/ecam_descripteurs.ske
 synchro_descripteurs.ske -> ../generic_synchro/ecam_descripteurs.ske
 ucsd_descripteurs.ske    -> ../generic_ccd/ucsd_ecam_descripteurs.skeOn voit que 3 appels à cette procédure seront lancés pour la contribution de ecam au header du fichier FITS final (remarque celui nommé synchro.. est un cas special pour les Flats)

La procédure travaille ainsi:

si on lui donne un nom en argument, ce nom est utilisé pour choisir le fichier squelette (rem, tunix sert comme identificateur unique pour nommer le fichier temporaire). Exemple:

 archive_applic_descripteurs.prc tunix ucsd

si rien n'est précisé, alors les fichiers suivants selon ajoutés, s'ils existent:

descripteurs.ske
<application>_descripteurs.ske  (ex: ecam_descripteurs.ske)

 

 

LW 06/05/2020