18 Juin 2020 / Perte de données Eros II

La dernière présentation abordant la question des fichiers perdus ou inutilisable.

A bientôt.

Perte de données Eros II : transparents seuls, en format PDF.

Perte de données Eros II – notes : transparents annotés, en format PDF.

Publié dans Non classé | Laisser un commentaire

16 Juin 2020 / Migration des données Eros II

La suite des présentations, à savoir la situation des données Eros II après la migration vers Irods.

J’ai réservé la question des difficultés rencontrées à une troisième présentation. De ce fait, et puisque j’avais un peu de place, j’en ai profité pour présenter quelques outils permettant d’accéder plus confortablement aux données.

A bientôt.

Migration des Eros II : transparents seuls, en format PDF.

Les Migration des Eros II – notes : transparents annotés, en format PDF.

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

9 Juin 2020 / Les données Eros II

Comme promis (:-)), je viens de mettre en ligne la première partie de la présentation sur la réorganisation des données Eros II dans Irods : Les données Eros II. L’objectif est autant de décrire la structure des données que les termes utilisés.

Une deuxième partie présentera la migration vers Irods et l’organisation adoptée à cette occasion. La présentation fera aussi le point sur les différentes difficultés rencontrées.

A bientôt.

Les données Eros II : transparents seuls, en format PDF.

Les données Eros II – notes : transparents annotés, en format PDF.

Publié dans Eros2 | Marqué avec , , | 2 commentaires

28 Janvier 2020 / Valorisation des données Eros – Préparation

Réunion préparatoire

Participants : Marc Moniez, Jim Rich, Jean-Baptiste Marquette (vidéo), Tristan Blaineau, Jean-Noël Albert

Excusé : Réza Ansari

Cette réunion est destinée à préparer une rencontre avec des représentants du Centre de calcul dans le but de pérenniser les données de l’expérience Eros et de permettre leur diffusion.
Cet objectif, longtemps évoqué, a été remis d’actualité par un contact du Centre de calcul suite à la réactualisation des données Eros conduite depuis un peu plus de deux ans, à un rythme dépendant des possibilités de chacun.

La réunion est organisée autour deux thèmes principaux : les souhaits d’Eros en termes d’archivage et de diffusion de ces données ; et la préparation d’une présentation de l’expérience au représentant du CC, des raisons de la réactivation des données et des difficultés rencontrées.

Jean-Baptiste introduit la discussion par une observation sur la différence fondamentale entre les données d’astronomie et les données des accélérateurs : en astronomie, les données ne sont pas reproductibles, elles résultent d’observations qui ne pourront plus jamais être refaites, alors que les données issues des accélérateurs peuvent être reproduites, même si c’est souvent complexe et couteux. Les données d’astronomie sont donc d’autant plus sensibles à toutes formes de destruction ou de corruptions et leur préservation un sujet particulièrement critique.
Marc enchaîne par un rappel rapide de l’expérience et pointe le fait que les données d’astronomie anciennes sont très précieuses et cite plusieurs exemples.
Puis Marc et Jim évoquent rapidement les motivations pour la réactivation des données Eros en liaison avec la recherche de lentilles gravitationnelles de longues durées, à l’origine de la thèse de Tristan.
Marc fait également état des différents types de données « périphériques » à Eros 2, dont les données Eros 1/plaque, les données Eros 1/ccd, et les données Macho et peut-être à termes Super Macho.
Enfin, Marc évoque un couplage possible de la base de données Eros 2 avec LSST.

  • ce point est à approfondir

En parallèle, Marc fait également état d’informations qu’il serait utile de conserver en sus des données elles-mêmes, à savoir les logbooks des prises de données – qu’il faudra retrouver – et les cahiers d’observation – qu’il serait intéressant de scanner.
Jim fait remarquer que scanner 7 ans de cahiers de manip suppose un effort conséquent.

Jean-Baptiste fait état d’un nouvel équipement à l’Observatoire de Meudon pour la numérisation des plaques anciennes. Le traitement de ces plaques pourrait être à négocier avec les représentants de l’Observatoire. Cela permettrait de récupérer les images d’Eros 1/plaque sous une forme numérique.

  • JB indique un correspondant possible et une future réunion dans les environs où les différentes personnes intéressées pourraient être présentes – à préciser.

Jean-Baptiste rapporte son travail consistant en la normalisation des images Eros 2 (question de l’orientation des images) et la reconstruction des entêtes FITS enrichies d’informations WCS.
Jim et JNA tombent d’accord sur le fait que les images originales ne doivent pas être touchées, mais qu’une nouvelle branche doit être créée pour conserver ces nouvelles versions en parallèle à la branche historique.

JNA fait état de sa préoccupation concernant la perte de fait des données originales Eros 2, les données « brutes », conservées sur des DLT à Saclay mais qui n’ont hélas pas été transférées sur un support plus actuel.

  • Nous sommes ici en plein dans la problématique de l’archivage pérenne des données scientifiques.

Marc et Jim considèrent que, compte tenu des difficultés liées à la construction des images réduites (soucis avec les flats utilisés pour le deflatage), ces images n’auraient sans doute plus beaucoup d’intérêts.
Jean-Baptiste fait état de nouvelles techniques de réduction qu’il pourrait être intéressant d’évaluer.
JNA signale qu’il existe à Lyon quelques images brutes et des flats qu’il va rechercher et mettre à la disposition de Jean-Baptiste.

JNA signale en outre le souci concernant l’accès aux catalogues d’étoiles et aux fichiers de suivis.

  • un autre aspect central de la pérennisation des données scientifiques.

Jim et Marc semblent penser que les informations contenues dans les courbes de lumière ASCII sont suffisantes.

A l’issue de cette discussion, il semble acquis que la première étape de l’archivage des données Eros doit concerner les images réduites, présentes au CC, et les courbes de lumière ASCII.
JNA insiste sur le fait qu’il s’agit d’un domaine nouveau pour nous et qu’il convient sans doute d’avancer par étape, sur des données que nous connaissons et maitrisons bien, mais que cela ne doit pas nous interdire d’étendre la démarche si les premiers résultats sont satisfaisants.
Il ressort aussi clairement que les discussions avec le CC devront porter sur la démarche à suivre. Le CC devra nous guider sur les métadonnées à fournir et les formats de présentation. Toutes les informations nécessaires sont sans doute en notre possession, typiquement dans la base de données, mais il conviendra certainement de faire un gros effort pour se fondre dans un moule préexistant.

En parallèle, JNA signale l’accord du service informatique du IJCLab/ex-LAL pour fournir les moyens nécessaires à mettre en place une seconde source pour les données Eros.

  • Il conviendra d’évaluer la possibilité d’indexer les fichiers de cette seconde source dans la base de données.

Une première répartition des tâches pour la réunion avec le CC serait :

  • une brève présentation des motivations scientifiques de l’expérience Eros ainsi que des raisons pour avoir réactiver ces données après 25 ans de sommeil
    • typiquement Marc
  • une vue rapide du flux des données Eros, depuis les images brutes de La Silla aux courbes de lumière ASCII
    • Jna/Réza – à préciser
  • une vue rapide de l’organisation de la base de données
    • Jna
  • un état des difficultés rencontrées durant la migration
    • Jna

Et du côté du CC :

  • la problématique de l’archivage des données scientifiques
  • la question de l’interopérabilité et des relations avec l’Observatoire virtuel et le CDS
  • une présentation des étapes nécessaires pour aboutir

A faire

  • réactualiser le compte de Jean-Baptiste au CC [JNA]
  • trouver des images brutes et des flats pour Jean-Baptiste [JNA]
  • préparer la sauvegarde à Lyon des images normalisées par Jean-Baptiste [JNA]
    • question du nommage de ces nouvelles images [JNA, JB]
  • accélérer la sauvegarde des données Macho qui encombrent le disque de travail Eros à Lyon [JNA]
  • répartir les présentations
  • préparer et faire circuler les transparents des présentations
  • informer le CC de l’état de la réflexion Eros

 

Publié dans Eros1, Eros2, Macho | Laisser un commentaire

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