Eros Anastasis

Les courbes de lumière ASCII contiennent une sélection des mesures réalisées pour les étoiles suivies par l’expérience. Ces fichiers ont été créés à partir des fichiers de suivi, très vraisemblablement de la production dite « P5 », et seulement pour 7 programmes scientifiques : Beta Scuti (bs), Centre galactique (cg), Gamma Normae (gn), Gamma Scuti (gs), Lmc (lm), Smc (sm), Theta Muscae (tm).

Chaque courbe de lumière ASCII est contenue dans un fichier dont le nom est constitué de l’identifiant de l’étoile et de l’extension « .time ». Cet identifiant est référencé dans un catalogue ASCII. Le catalogue porte le nom simplifié du quart de CCD concerné, constitué du code du programme scientifique, du code du champ, du numéro du CCD et de l’identification du quart de CCD (le code caméra est absent, les courbes de lumière regroupant les mesures réalisées dans les couleurs bleue et rouge). Par exemple, le catalogue lm0570n.cat contient la liste des étoiles du programme scientifique LMC, pour le champ 057, le CCD 0 et le quart n. Les étoiles suivies sont nommées à partir du nom du catalogue et d’un numéro unique. Par exemple, l’étoile lm0570n29305. La courbe de lumière de cette étoile est donc conservée dans le fichier lm0570n29305.time.

Un tel fichier contient une ligne par mesure réalisée, chaque ligne étant constituée de 5 colonnes : la date de la mesure, exprimée en Julian Days décalés, et les magnitudes bleues et rouges et erreurs sur ces magnitudes.

Un jour Julien est un jour exprimé dans un calendrier arbitraire dont l’origine est à plus de 60 siècles dans le passé. La conversion des dates contemporaines en jours juliens donne donc des valeurs dépassant les 2 millions et demi. Pas très pratique. Pour simplifier l’écriture, les dates juliennes enregistrées dans les courbes de lumière sont donc décalées d’une certaine valeur. Pour LMC, et sans doute SMC, le décalage est de 2 450 000. La date de référence est la date d’exposition de l’image, qui est la date de début de la prise de vue, exprimée en temps universel. C’est grâce à l’aide de Jim Rich et à la sagacité de Marc Moniez qu’il a été possible de reconstituer cette logique.

Le serveur de l’IMCCE (Institut de mécanique céleste et de calcul des éphémérides) propose une page qui permet de convertir une date calendaire et jour julien et réciproquement. Cette page permet donc de déterminer à quel jour usuel correspond la date du 2 450 000 julien. Quant à Java, ajouter du temps au temps n’est qu’un jeu pour lui. Il est donc aisé d’imaginer une application permettant de mettre en correspondance les mesures enregistrées dans les courbes de lumière et les images où ces mesures ont été réalisées.

Là où la chose se complique est que cette martingale ne semble pas fonctionner pour les Bras Spiraux. Marc estime que le décalage choisi pour ces programmes diffère de celui du LMC, et vraisemblablement du SMC. pour aller plus loin pour ces autres programmes, il faudrait pouvoir accéder au code source utilisé pour la construction des courbes de lumière des différents groupes, ou disposer d’un autre fil d’Ariane…

Références

• Jour Julien
  • https://fr.wikipedia.org/wiki/Jour_julien
• IMCCE – Institut de mécanique céleste et de calcul des éphémérides
  • https://www.imcce.fr/
• Convertisseur Julien calendaire de l’IMCCE
  • https://promenade.imcce.fr/fr/pages2/278.html
• Calcul des dates en Java
  • https://docs.oracle.com/javase/8/docs/api/java/util/Calendar.html

Les entêtes FITS des images Eros sont désormais enregistrés dans la base de données sous une forme BLOB comprimé dans une table associée à la table des images. L’accès aux entêtes FITS est donc sensiblement plus facile et surtout plus rapide.

Cependant, quelques entêtes font défaut. Cela concerne bien évidemment les images référencées dans la base de données mais pour lesquelles les fichiers FITS manquent, et plusieurs images dont l’entête est manifestement corrompu.

L’application FitsHeader permet d’accéder directement à ces entêtes à partir du nom de l’image. FitsHeader continue à présenter les entêtes FITS à partir des fichiers des images, qu’ils soient locaux ou dans iRods.

Trois formats de présentation sont proposés :

• le format raw FITS, appelé header dans FitsHeader, où les lignes sont calées sur 80 caractères sans terminateur ;
  • ce format est compatible avec la norme FITS si ce n’est que la présentation de l’entête s’arrête à la clé END et n’est pas alignée sur des blocs de 36 lignes ;
• le format properties, où les données sont présentées comme des lignes clé = valeur, compatibles avec les langages de programmation usuels (Java, Groovy, Python, …) ;
• le format keys, similaire au format raw, mais où les lignes sont terminées par le terminateur de ligne de la plateforme, ce qui permet un affichage plus simple et la mise en place de filtres standards à base de grep, awk, sed, …

Le format keys est le format utilisé par défaut si la présentation est faite à l’écran. Le format header est utilisé lorsque l’entête est enregistré dans un fichier.

Exemples :

$ FitsHeader bs30012tbraf10118 | head
SIMPLE  =                    T
BITPIX  =                   16
NAXIS   =                    2
NAXIS1  =                 2048
NAXIS2  =                 2048
NUMCAM  =                    2
NUMCCD  =                    2
NUMADC  =                    1
CCDACT  = '01234567  '
NUMSEQ  =                   95

Cette application est disponible avec la version 6.6.7 du projet ErosDb.

La description des images dans la base de données a été enrichie et actualisée.

Les temps et dates d’observation ont été corrigés et augmentés. La précédente version proposait la nuit d’observation, déduite du nom de l’image, le temps d’exposition, obtenu de l’entête FITS, et les temps de début d’observation en heure local (TM-START) et temps sidéral (TS-START). Ces deux dernières informations étaient enregistrées comme des dates, alors qu’il ne s’agit que d’un nombre de secondes, et les données conservées étaient inexploitables.

La nouvelle organisation conserve :

• la nuit, comme une date ;
• le temps d’exposition, comme un nombre de secondes (TM-EXPOS);

et ajoute :

• la date d’observation, date de fin d’observation en temps local (DATE) ;
• la date d’exposition, date de début d’observation en temps universel (DATE-EXP) ;
• et les temps de début et fin d’observation, en temps local, temps universel et temps sidéral (TM-START, TM-END, TU-START, TU-END, TS-START et TS-END), comme un nombre de secondes.

Ces informations proviennent de l’entête FITS et correspondent donc aux conventions Eros.

Par ailleurs, le code d’erreur associé à l’image a été corrigé et actualisé de manière à mieux qualifier les images.

Les principaux codes en vigueur :

• BADHDR : l’entête est corrompu et ne peut être lu correctement ;
• BADTIME : un ou plusieurs temps ou dates sont incorrects ou incompatibles avec la nuit ;
  • ceci concerne certains temps de plusieurs centaines d’heures et des dates antérieures à la date de la nuit ;
• MISSKEY : des clés FITS, essentiellement les clés correspondant aux temps et aux dates, font défaut ;
• NOFILE : l’image FITS n’existe pas – ou n’a pas été transférée ;
  • cela concerne essentiellement : les programmes Monté Carlo, non migrés ; et le programme Naine Rouge – dont les images semblent perdues ;
• OK : l’image a passé les différents cribles et est considérée comme valide.

Situation :

Erreur  Count
------- -------
BAD         684
BADHDR      140
BADTIME    8346
MISSKEY    6865
NOFILE   143567
OK      1867970

Les images « calibrées », ou plus précisément les images « composées avec calibration astrométrique » sont désormais intégrées au système de gestion des données Eros. Elles sont disponibles dans iRods, à l’emplacement standard, et enregistrées dans la base de données.

Les noms de ces images ont été modifiés conformément à la note du 10 Janvier, Migration des images calibrées, et leur code de traitement est donc w. Elles peuvent être inspectées, par exemple grâce à ReportImages ou ReportImageFiles, ou accédées par GetImages.

Rappel : ces images correspondent à des quarts de CCD. Leur code de sous-image est donc k, l, m, ou n.

Emplacement des images dans iRods :

/eros/data/eros2/fits/<pg>/<pg><chp>/<pg><chp><k><c>/

avec :

• pg: le code du programme scientifique (ou « objet ») sur deux lettres ;
• chp: le code du champ, sur 3 lettres ou chiffres ;
• k: le code de la caméra (0 ou 1) ;
• c: le code du CCD (0 à 7) ;

Exemple :

$ ReportImageFiles bs 300 1 2 traitement=w

Directory                              Nom                   Taille Creation
-------------------------------------- --------------------- ------ -----------------
/eros/data/eros2/fits/bs/bs300/bs30012 bs30012nbw6a3150.fits 6.1853 24-Jan-2019 12:54
/eros/data/eros2/fits/bs/bs300/bs30012 bs30012lbw6a3150.fits 6.1853 24-Jan-2019 12:54
/eros/data/eros2/fits/bs/bs300/bs30012 bs30012mbw6a3150.fits 6.1853 24-Jan-2019 12:54
/eros/data/eros2/fits/bs/bs300/bs30012 bs30012kbw6a3150.fits  6.188 24-Jan-2019 12:54

Dans un post de septembre (@14 Septembre 2018 / Images compositées calibrées), je décrivais la situation des images calibrées astronomiquement et les difficultés liées à leur nom, incompatible avec les contraintes de la base de données Eros, et leur entête FITS.

Dans cette note, je décrirais la procédure envisagée pour leur normalisation et leur intégration au système de stockage et d’indexation de l’expérience.

La situation

Les images calibrées conservées dans le HPSS présentent deux difficultés :

• leur nom n’est pas compatible avec les contraintes imposées par la base de données ErosDb ;
• la clé FITS FILENAME de leur entête ne correspond pas au nom du fichier.

La clé FILENAME

Pour ce que j’ai pu comprendre en étudiant différents cas, l’image calibrée astronomiquement a été produite à partir d’une image composée de type « x ». Durant ce processus, l’entête FITS de l’image composée a été reprise, enrichie de clés décrivant les traitements appliqués. Toutefois, les clés CDELT1 et CDELT2 semblent avoir disparues. Quant à la clé DATE-OBS, elle a été normalisée afin d’être conforme aux recommandations FITS.

Mais la clé FILENAME de l’image calibrée n’a pas été adaptée. Elle fait donc toujours référence à l’image composée initiale.

Le nom du fichier

Le nom attribué au fichier FITS de l’image calibrée est une forme réduite du nom de l’image composée d’origine où ne sont conservés que le code du programme scientifique, du champ, du CCD, du quart dans ce CCD et du filtre.

Ce format, plus simple, est cependant incompatible avec les contraintes mises en place dans la base de données afin de la protéger d’erreurs de manipulation.

Pour faire entrer les images calibrées dans le système de référencement Eros, il faut donc soit gauchir les contraintes de la base de données sur le nom des images, soit adapter les noms des images calibrées aux contraintes de la base de données.

L’idée est donc de repartir du nom de l’image composée d’origine et de modifier le code du traitement de « x » (ou éventuellement « c ») en « w ».

Campagne de migration

La migration des images calibrées est assez semblable aux autres migrations avec la difficulté d’un traitement préalable à leur sauvegarde dans iRods et leur enregistrement dans la base de données.

Lors de cette phase :

1. le nom de l’image est déduit du nom de l’image composé initiale en changeant le code du traitement en « w » ;
2. le nom du fichier FITS est modifié de manière à correspondre au nouveau nom de l’image ;
3. la valeur de la clé FITS est modifiée de manière à refléter le nom réel du fichier FITS ;
4. le fichier est sauvé dans iRods, dans un répertoire correspondant aux caractéristiques de l’image (programme, champ, ccd, …) ;
5. les paramètres de l’image et du fichier sont enregistrés dans la base de données.

A l’issue de la migration, l’archive TAR issue du HPSS est placée dans un répertoire spécifique iRods. L’archive est conservée inchangée ! Ainsi, en cas d’erreur dans la procédure de migration, il sera possible de revenir aux fichiers d’origine.

Les efforts visant à étendre l’accès à iRods dans ErosDb ont pris plus de temps que prévus mais sont finalement achevés (@3 Décembre 2018 / Jargon NIO). Il est donc temps de terminer la migration des images.

Ceci concerne :

• les quelques archives dans des formats non standard – par rapport aux procédures de migration ;
• l’essentiel des images utilisées pour la réduction des images : coupoles et ciels ;
• les images des programmes dit Monte Carlo ;
• le programme Naines rouges;
• les images calibrées astronomiquement.

Continuer la lecture →

En analysant la base de données, je me suis aperçu que les enregistrements décrivant les images FITS indiquaient la date, mais pas de l’heure de la prise de vue.

En regardant les entêtes FITS des premières images, j’ai trouvé pas moins de 8 clés correspondant à des dates et des heures:

DATE-OBS= '20/08/96  '
TM-START= '06:17:59  '
TM-END  = '06:21:04  '
TU-START= '10:17:59  '
TU-END  = '10:21:04  '
TS-START= '03:31:12  '
TS-END  = '03:34:17  '
DATE    = '20/08/96  '

Les dates ne sont évidemment pas au standard Y2K, sorti en 1997. Les dernières images semblent avoir des clés DATE et DATE-OBS normalisées, et un mot-clé supplémentaire:

DATE-OBS= '27/02/2003'
TM-START= '01:59:42  '
TM-END  = '02:03:05  '
DATE-EXP= '2003-02-27T04:59:42'
TU-START= '04:59:42  '
TU-END  = '05:03:05  '
TS-START= '10:43:15  '
TS-END  = '10:46:39  '
DATE    = '2003-02-27L02:04:28'

A part les clés DATE et DATE-OBS, je n’ai pas trouvé trace des autres clés dans les différents dictionnaires FITS que j’ai pu consulter. Je peux imaginer que «TU» fait référence à un temps « universel ». «TM» pourrait représenter le temps calendaire local. Quid de «TS» ?

Par ailleurs, DATE utilise un indicateur d’heure « L », qui pourrait signifier « local », mais dont je n’ai trouvé trace nul part. Et pourquoi y a-t-il un décalage entre cette heure et la clé TM-END… ? Quant à DATE-EXP, elle semble indiquer la date de début de la prise de vue en TU…

D’où la question, quelle heure conviendrait-il de conserver dans la base de données?

Question subsidiaire : existe-t-il un document décrivant les clés utilisées par Eros?

StarsFinder est un utilitaire permettant de trouver les étoiles détectées par l’expérience Eros connaissant l’ascension droite et la déclinaison (ou ra/dec) de la zone de recherche et la largeur de cette zone.

Dans la précédente version, une vigoureuse optimisation permettait de trouver facilement les étoiles lorsque la zone était de petite taille. Mais lorsque la zone dépassait la dimension d’un quart de CCD, le programme ne conservait que les étoiles des quatre coins…

La correction est désormais effectuée, mais elle suppose de passer à ErosDb 6.6.0 (voir le post à ce sujet).

Continuer la lecture →

Le site web d’ErosDb a été rajeuni. L’ancienne version est conservée, momentanément du moins, dans un sous-répertoire.

La nouvelle version du site regroupe différentes informations sur l’environnement ErosDb, sur l’expérience Eros, les distributions stables de l’environnement et des notes pour la configuration des logiciels utilisés.

Références:

• Le site ErosDbII: http://eros.lal.in2p3.fr/ErosDB/
• L’ancien site ErosDb: http://eros.lal.in2p3.fr/ErosDB/ErosDb99/ErosDB.html