2 Juin 2021 / L’espace Eros au CCIN2P3

Attention ! Eros rejoint la cour des grands au CCIN2P3 : son espace de travail SPS est renommé /sps/eros

Les répertoires utilisateurs sont donc : /sps/eros/users

L’espace logiciel est : /sps/eros/softs

Et pour ErosDb III : /sps/eros/softs/ErosDbIII

Publié dans Non classé | Laisser un commentaire

2 Juin 2021 / ErosDb III

Une nouvelle phase du projet ErosDb entre en route sous l’appellation ErosDb III.

ErosDb II était dédié à la migration des données vers le système de stockage distribué Irods ainsi qu’à leur réorganisation sous la forme de différentes arborescences.

Cette étape achevée, les outils utilisés n’ayant plus beaucoup d’utilité, il convenait de se concentrer sur l’accès aux données, à leur documentation et à leur pérennisation en vue d’un large accès.

C’est le rôle d’ErosDb III – ce changement s’accompagne d’un abandon de Java 8 pour passer à Java 16, plus fiable et plus efficace, et la refonte du site web autour de MkDocs.

Le site porte toujours le nom http://eros.lal.in2p3.fr/ErosDB/ – le transfert vers IJCLab ne semblant pas être une priorité… J’ai bien demandé un hébergement au CC, mais depuis un mois, aucune réponse…

Outils améliorés

  • DecodeName : décodage du nom des images, des suivis, …
  • ReportImages : recherche des images dans la base de données.
  • ReportSuivis : recherche des suivis dans la base de données.
  • GetImages : recherche et transfert des fichiers contentant les images.
  • GetSuivis : recherche et transfert des fichiers contenant les suivis.

Les modifications concernent la formulation des requêtes et de nouveaux opérateurs inspirés de SQL.

Les outils GetXxx permettent d’accéder aux paramètres des fichiers des images ou des suivis et de les recopier depuis Irods.

Outils conservés

  • FitsHeader : présentation de l’entête FITS d’une image soit à partir d’un fichier local soit à partir de la base de données.
  • StarsFinder : recherche d’étoiles dans la base de données, accès et transfert de leurs paramètres, leurs courbes de lumière, leurs images, leurs suivis.

Références

 

Publié dans Eros1, Eros2 | Laisser un commentaire

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