8 Novembre 2019 Ressources au CC

Compte-rendu de la réunion technique du 4 Novembre 2019.

Présents: Marc Moniez, Tristan Blaineau, Jean-Noël Albert

Thème:

  • Le sujet de la réunion était de déterminer les besoins de l’expérience pour l’année à venir, et si possible les années suivantes, et de transmettre ces besoins au Centre de calcul afin de pouvoir y travailler sur les données Eros.
  • Nous avons aussi discuté du nettoyage de l’espace occupé par des données obsolètes.

Rapporteur:

  • Ce post est basé sur les notes de Marc Moniez

Demande de ressources

Temps CPU

  • l’utilisation du Centre pour l’année 2019 a été de 330 000 heures, soit 275 000 heures, soit … 3 CPU;
  • la période de calcul va de Mai à Juillet puis Septembre;
  • nous avons demandé 200 000 heures par trimestre pour 2020.

Stockage Disque SPS

  • nous disposons de 5 TB dans l’espace de stockage semi-permanent SPS, occupé à 75%;
  • cet espace est actuellement utilisé comme tampon pour la récupération des images Macho, avant leur transfert vers iRods;
  • nous avons demandé 2 fois 1.5 TB pour les deux premiers trimestres de 2020 afin de disposer d’un tampon pour les données Super Macho et la vérification des transferts des données Eros du HPSS vers iRods.

Stockage Cartouches iRods

  • nous utilisons actuellement 48 TB d’espace de stockage iRods cartouches;
  • cet espace contient la copie des données Eros transférées du HPSS et réorganisées de manière à permettre un accès plus aisé;
  • la stratégie de réorganisation à consister à mettre en ligne les données sans effacer les archives transférées;
  • nous occupons donc actuellement deux fois plus d’espace que réellement nécessaire (aka: 24 TB);
    • la validation des transferts va occuper une partie des deux trimestres à venir;
    • une fois terminé, les doublons seront effacés;
  • nous avons donc demandé 2 fois 10 TB dans l’espace de stockage cartouche de iRods afin de passer le cap de cette vérification et permettre l’intégration des données Macho et Super Macho.

Stockage HPSS

  • nous utilisons 28 TB dans le HPSS, dont environ 24 TB de données de l’expérience actuellement transférées dans iRods;
    • ce qui fait qu’un fichier Eros existe actuellement 3 fois…
  • il reste donc dans le HPSS environ 4 TB de données « non officielles »;
  • nous n’avons bien sûr demandé aucune ressource (autre que iRods – voir ci-dessus).

Base de données

  • nous avons demandé un accroissement de 200 GB de l’espace Oracle afin de pouvoir y enregistrer la description des fichiers Macho et Super Macho.

2021 – 2022

  • il est bien sûr délicat de faire des demandes à long terme, mais comme au moins une thèse est en cours, nous avons anticipé les demandes pour les 2 années à suivre sur la base des demandes de 2020, soit 1 million d’heures CPU / an et 10 TB cartouches / an.

Nettoyage des espaces de stockage

Un nombre important de fichiers privés sont conservés dans le HPSS et dans l’espace disque commun SPS [un état des lieux doit être fait…]. Dans SPS, il s’agit de copies de l’ancien espace GROUP_DIR/AFS. La situation de HPSS est plus confuse.

La décision prise est d’essayer de dégager ces très vieux fichiers, si possible en conservant quelque part des archives (version moderne de « la mise à la cave »).

Le plan est le suivant :

  • établir un état des lieux par utilisateur
  • contacter les utilisateurs pour leur demander de faire eux-mêmes du ménage
    • ou du moins nous donner des directives concernant ces vieux fichiers (codes, données, documents)
  • supprimer ou archiver les données

Sauvegarde des données Eros

Marc doit contacter le service informatique du LAL pour tenter d’avoir un duplicata local des données Eros.

Cela pourrait atteindre 25 TB.

Publié dans Eros2 | Marqué avec , , , | Laisser un commentaire

Disponibilité des données Macho au CCIN2P3

Objectif : recopier au Centre de calcul les données de l’expérience Macho afin de pouvoir les associer aux données Eros.

Participants : Marc Moniez (Marc), Tristan Blaineau (Tristan), Jean-Noël Albert (Jna)

Le volume des données est le suivant :

  • courbes de lumière sous une forme comprimée : 700 Go
  • images : 7 To

Continuer la lecture

Publié dans Macho | Laisser un commentaire

9 Avril 2019 Le Maistre des Temps

Jean-Baptiste Marquette nous a transmis un bien précieux sous la forme d’un ensemble de catalogues de dates liées aux courbes de lumière Eros 2.

Mon sentiment est, si Jean-Baptiste est d’accord, de joindre ces données aux autres données Eros 2, typiquement dans l’arborescence lightcurves. Grâce à l’indexation des fichiers dans les archives TAR/GZ, il n’y a même pas à décomprimer.

Je propose aussi d’enregistrer dans la base de données différents éléments de ces tables.

Les dates sont regroupées par programme scientifique (appelé aussi objet) et champ. Chaque catalogue est constitué de 5 colonnes :

  • le « discriminant » de l’image, à savoir la date codée sur 4 caractères et le numéro de prise de vue – ce qui suffit puisque toutes les images d’un champ, quelques soit la caméra ou le CCD sont prises en même temps ;
  • la date exprimée en MJD (Modified Julian Day) – une date au standard Julien, mais débutant le 17 novembre 1858 à 0 heure ;
  • la date en format ISO, sans l’indicateur Z de la Time Zone UTC – mais c’est implicite, je pense, en astro ;
  • la date EHJD, pour Eros Heliocentric Julian Day, qui correspond à la date julienne héliocentrique décalée de 2 450 000 jours – soit le 9 Octobre 1995, à 12 heures ;
  • la date en secondes, selon la convention « unix », mais calculée depuis le 1 Janvier 1990, à 0 heure (l’origine UNIX est le 1 Janvier 1970).

Un point important, et pour lequel j’avais un doute, c’est que toutes les courbes de lumière ont la même origine.

Par ailleurs, il m’a semblé – mais je n’ai vérifié que quelques courbes de lumière – que si l’image n’a pas pu être traitée par la photométrie, il n’y a pas de points de mesure dans les courbes de lumière, et donc (?) pas d’entrée dans les catalogues de dates. Ceci étant, si la photométrie a échoué, c’est que l’image ne doit pas être terrible…

Mais cela implique aussi que ces informations ne sont pas disponibles pour les « programmes mineurs », pour lesquels il n’existe pas de courbes de lumière.

Par curiosité, j’ai regardé le décalage entre les dates MJD et EHJD pour un champ. Sans surprise, c’est une assez jolie sinusoïde.

J’ai aussi essayé de comparer les dates de ces catalogues aux dates « d’exposition » indiquées dans les entêtes FITS – et enregistrées depuis peu dans la base de données. La date « d’exposition », dans la terminologie Eros 2, correspond à la date de début d’observation en UTC. A l’inverse, la date « d’observation » correspond à la date de fin d’observation en temps local.

Là, c’est plus compliqué. J’observe d’importantes variations que, jusqu’ici (optimiste, hein !), je ne comprends pas très bien. Les décalages semblent se situer pour l’essentiel dans la gamme 20-350 secondes, avec un pic à 50-150 s, alors que les temps d’exposition (donné par la clé FITS TM-EXPOS) sont soit de 120 s, soit pour SMC et LMC de 300 s, avec des pics secondaires à 180 et 450 pour LMC et à 600 pour SMC.

Mais cela m’a permis de détecter des images sans date d’exposition ou avec des dates d’exposition plus qu’étranges, ce que je vais essayer de comprendre (+/- 4% des images).

Propositions

  • Sauver dans iRods et indexer l’archive de Jean-Baptiste contenant les catalogues de dates.
  • Ajouter à la description des images dans la base de données les 3 informations suivantes :
    • la date EHJD, figurant dans les courbes de lumière et dans les catalogues de dates ;
    • la date MJD correspondante, fournie par le catalogue de dates ;
    • la date UTC, que l’on pourrait appeler « date mesurée ».

La date au standard UNIX est sans doute moins utile car il est assez simple de la reconstruire à partir de la date UTC, et les requêtes à la base de données se feront plutôt sur la date EHJD, afin de pouvoir présenter rapidement les informations additionnelles correspondant à une mesure (voir https://groups.lal.in2p3.fr/erosanastasis/2019/04/02/2-avril-2019-courbes-de-lumiere-augmentees/).

Comme il ne s’agit que de charger des données dans la base de données à partir de fichiers textes, l’opération pourra être rapide.

Publié dans Non classé | Marqué avec , , , | Un commentaire

2 Avril 2019 / Courbes de lumière augmentées

La possibilité de mettre en correspondance les mesures des courbes de lumière ASCII et les images [Des courbes de lumière aux images] permet d’envisager une application associant à chaque mesure différentes informations relatives aux prises de vue ainsi qu’aux traitements photométriques réalisés lors de la construction des fichiers de suivi.

En effet, lors de l’entrée des images au Centre de calcul, différentes informations enregistrées dans les entêtes FITS ont été conservées dans la base de données. De même, lors de la réalisation des photométries, des informations ont été extraites des fichiers de log produits par le programme Peida et enregistrées dans cette même base de données.

Il est donc aisé, connaissant l’image, et en supposant que les traitements ont bien été réalisés dans le cadre de la Production P5, de retrouver ces informations et de les afficher sous la forme de ‟courbes de lumière augmentées”

Les informations disponibles liées aux images :

  • la décomposition des attributs de l’image en termes de programme scientifique, champ, CCD, …
  • les dates et heures de prise de vue en temps local, temps universel, temps sidéral ;
  • des informations sur la prise de vue : AirMass, FondCiel, NbStar, Seeing, SigFond, SigmaX, SigmaY, GoodCCD, VQual, CoefCal ;

Les informations disponibles liées aux photométries :

  • un code de traitement, dont la valeur 1 correspond à un succès de l’exécution du programme ;
  • des informations issues des logs Peida : Fond, SigFond, BadPixel, SigX, SigY, Rho, FitFluxOk, Absorption, DeltaX, DeltaY, FgCal ;

L’intérêt d’une telle application – et les modalités de sa mise en place – sont à préciser avec les utilisateurs potentiels.

Son usage sera limité, pour le moment espérons, à LMC, et peut-être SMC.

Publié dans Non classé | Un commentaire

2 Avril 2019 / Des courbes de lumière aux images

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

Publié dans Non classé | Laisser un commentaire

20 Février 2019 / Les données Eros 1 CCD

Les données Eros 1 CCD sont à Lyon, dans le HPSS. Il semble admis que ce serait une bonne idée de les transférer dans iRods, au même titre que les données Eros 2. Le faible volume de données, moins de 300 GB, rend la chose possible. Par chance (!), l’organisation des données prévoie une place pour Eros 1.

L’arborescence des données dans iRods est la suivante :

/eros
    /eros/data
        /eros/data/eros2
            /eros/data/eros2/fits
            /eros/data/eros2/fits-headers
            /eros/data/eros2/fits-props
            /eros/data/eros2/lightcurves
            /eros/data/eros2/references
            /eros/data/eros2/suivis
            /eros/data/eros2/tars

Il est donc facile de créer une arborescence similaire pour Eros 1 CCD.

/eros
    /eros/data
        /eros/data/eros1
            /eros/data/eros1/fits
               ...

Là où la chose se complique c’est lorsqu’il s’agit d’enregistrer ces données dans la base de données.

Deux problèmes se posent : le choix fait d’utiliser les extensions des noms de fichier (leur type) pour représenter certaines caractéristiques des données ; et la multiplication de fichiers de même nom, discriminés uniquement par leur répertoire, ou pire, par le container Tar dans lequel ils résident.

Continuer la lecture

Publié dans Eros1 | Laisser un commentaire

6 Février 2019 / Entêtes FITS

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.

Publié dans Non classé | Laisser un commentaire

6 Février 2019 / Actualisation de la base de données

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
Publié dans Non classé | Laisser un commentaire

6 Février 2019 / Images calibrées

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
Publié dans Non classé | Laisser un commentaire

10 Janvier 2019 / Migration des images calibrées

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.

Publié dans Non classé | Un commentaire