Données EROS vers CDS (2)
Réunion de préparation du transfert des données EROS vers le CDS
8 Septembre 2022
Présents: J.N. Albert, R. Ansari, B. Goldman, M. Moniez, J. Rich
Résumé des discussions
- On envisage un transfert des données vers le CDS par étapes, en commençant par LMC + SMC, puis CG, puis BS - Il pourra y avoir un nouveau release lorsque Jean-Baptiste aura retraité les images pour faire une nouvelle version des CdL avec photométrie améliorée
- Accord de principe sur l'écriture d'un papier décrivant brièvement EROS (la caméra, les programmes d'observation ...) , les données mises à disposition, en faisant référence aux papiers publiés pour les différents aspects de l'analyse (Tisserand et al, thèse Tisserand, Blaineau et al, Blending ... Jim est prêt de s'y investir avec l'aide des autres (MM, RA, BG, JNA, …). Ce papier décrira l'ensemble des données (LMC,SMC,CG,BS) , bien que le transfert au CDS se fasse par étape.
- Accord de principe sur le transfert des données sous forme de trois tables :
- Une table pour les images , table enrichie à partir des données TimeInfo des suivi et un lien pour accéder à chaque image (lien vers CC-IN2P3 ? )
- Une table pour les étoiles (Catalogue d'étoiles) , comprenant les étoiles avec CdL ascii, étendue éventuellement à toutes les étoiles - Voir point 4 ci-dessous
- Table CdL : Les courbes de lumière ascii , enrichies avec quelques infos extraites des suivi - le nom de l'image, l'information de Flux, ErreurFlux et Xi2, S9Pix pour chaque couleur
- Jim va analyser le catalogue complet - toutes les étoiles dans les suivi et vérifier si c'est raisonnable d'avoir une table complète des étoiles, y compris les étoiles non incluses dans les CdL ascii, SANS fournir leurs courbes de lumière
- Les quarts de CCD se recouvrent au niveau des fichiers de suivi. Une coupure au "cordeau" était appliquée dans l'analyse. Vérifier qu'il n'y a pas de recouvrement dans les fichiers CdL ascii
- Transfert des images / accès aux images : Les images de référence seront transférées au CDS et reprojetées pour être compatible avec le format Aladin - On aimerait pouvoir accéder aux images originales, par exemple à travers des liens (URL) vers le CC-IN2P3. Vérifier les images avec leur entête (astrométrie) et la compatibilité avec les infos du catalogues d'étoiles (x,y étoile en pixels)
- Jean-Noel Albert relance les échanges avec le CC-IN2P3 pour permettre un accès anonyme aux images dans iRods à travers des liens (URL) ou autre mécanisme - Mettre JR et RA dans la boucle
- JNA et Marc relance la possibilité de dupliquer les données EROS d'iRods en les recopiant vers Virtual Data. Voir avec Michel Jouvin et Guillaume Philippon la possibilité d'avoir les ressources appropriées ( ~ 50 TO )
- Il faudra préparer un lot de données correspondant à une petite fraction (par exemple 1 CCD d'une champ: Images + Cataloge d'étoiles + CdL) - ~ 1000 images , environ 10 GO pour permettre aux collègues du CDS de faire des tests. Jim se donne un mois pour préparer ce lot de données. Réza assistera Jim dans ce travail, et on compte sur l'aide de JNA.
- Organiser une réunion technique avec les gens du CDS pour aborder les différentes questions concernant ce transfert vers mi-octobre. Inviter aussi une ou deux personnes du CC-IN2P3 à cette réunion. Bertrand Goldman fera un sondage pour trouver un créneau, si possible dans la semaine du 17-21 octobre.
- On envisage le transfert des données EROS-I , Plaques d'abord, puis CCD après avoir complété le transfert des données EROS-II
Extraits des messages échangés en juillet, puis fin août et début septembre
1- Jean-Noel Albert sur de nouvelles infos et outils sur ErosDB
2- Bertrand Goldman sur les points à clarifier avant la réunion avec les gens du CDS
3- Jim Rich et Réza Ansari sur les données à mettre au CDS (3.a , 3.b , 3.c)
1- Extrait du message de Jean Noel Albert (23 juillet 2022)
Bonjour à tous,
Le site ErosMap décrit les observations réalisées par Eros 2 entre 1996 et 2003.
= > https://erosdb.in2p3.fr/ErosMap/
Il est construit par génération automatique des pages à partir d'informations extraites de la base de données.
Ces informations sont accessibles en format JSON (comprimé GZip pour accélérer le transfert).
Le site fournit des informations tel que le nombre d'images et de suivis, le nombre d'étoiles analysées,
le nombre de nuits d'observation, etc. par programmes, champs et quarts de CCD.
Des facilités pour la recherche des courbes de lumière à partir des positions des étoiles sont proposées
sous la forme d'un script Python et d'une page basée sur un script JavaScript.
= > https://erosdb.in2p3.fr/ErosMap/_notes/recherche-etoiles/
= > https://erosdb.in2p3.fr/ErosMap/_notes/StarsFinder/
Les recherches s'arrêtent à la présentation des noms des catalogues et des archives Tar des courbes de lumière
et à leur position dans Irods, puisque le site n'est pas encore connecté au serveur de fichiers.
Des études menées avec le CC montre qu'il existe des solutions. Mais il faut encore préciser la configuration souhaitée.
Extrait du message de Jim le 26 juillet 2022
Le match ascii-suivi a l'air de marcher via un 3-step procedure
suivi2fits (Reza): starinfo, timeinfo et LC -> fits format, un par quart de ccd-filter
matchcatsuivi.py (Jim): match LC(suivi) avec LC(ascii) using starid (rouge) et (xb,yb) (blue)
matchlc.py (Jim) match mesures(ascii) avec mesures(suivi) using mimile-jbm correspondance
entre teros(ascii) et imagecode. L'imagecode et aussi dans le suivi ce qui permet le match
des mesures pour les annees '90. Pour yr>=2000 j'utilise le yr code dans Tlocal(suivi) pour
corrige le bug (yr=a,b,c,d->'0' dans le suivi pour yr>2000)
A noter que cette procedure de match n'est pas documente a ma connaissance (pas certain
parcequ'il est bien connu que Mr. Rich ne lit jamais des documentations.....)
Cette etude a permis deja de confimer que le scatter observe entre mag(ascii) et 2.5log[flux(suivi)]
viens du decolorrelation des flux(suivi) avec seeing, airmass.....
Une example exteme est en PJ qui montre pour une etoile le zero-point (mag pour logflux=0)
plote vs sigma_psf.
C'est un cas extreme: le plupart de ces corrections sont de l'ordre 0.20 du sigma_mesure.
2- Extrait du message de Bertrand Goldman (31 août 2022 )
- s'assurer qu'il n'y a pas de problème avec une publication par morceaux:
- v1 rapidement LMC+SMC d'abord (avec nouvelle publication, spécifique LMC+SMC ou non), le reste (CG+bras) ensuite;
- puis v2 re-processé par Jean-Baptiste
- v1 rapidement LMC+SMC d'abord (avec nouvelle publication, spécifique LMC+SMC ou non), le reste (CG+bras) ensuite;
- volumes de données (l'outil de Jean-Noël donne les valeurs utiles) et produits (v1):
- catalogue d'étoiles (statique) et courbes de lumière dans Vizier,
- images de référence mais aussi individuelles (toutes projetées sur la grille Healpix) dans Aladin
- liens vers le CCPN
- je vois dans la page Eros Map les simulations monte-carlo, y aurait-il un intérêt quelconque à les inclure? et est-ce raisonnablement faisable?
- metadata des images?
- catalogue d'étoiles (statique) et courbes de lumière dans Vizier,
- autres questions et problèmes que j'ai oubliés
3.a Extrait du message de Jim Rich ( 6 septembre 2022)
Une des choses qu'il faut clarifier c'est quel donnees qu'on veut mettre au CDS.
Ci-dessous, un liste de choses dans les fichiers de suivi transforme en fits par Reza.
(Reza, is there more information that that?)
J'ai ajoute qqs commentaires sur l'interet ou non de cette info.
cheers
Jim
Starinfo:
In [5]: hdu=pyfits.open('lm00107nrp5.fits')
In [9]: hdu[1].header
TTYPE1 = 'StarId ' / label for field 1
TTYPE2 = 'XRef ' / label for field 2
TTYPE3 = 'FluxRef ' / label for field 3
TTYPE4 = 'FluxMean' / label for field 4
TTYPE5 = 'FluxSigma' / label for field 5
TTYPE6 = 'XPos ' / label for field 6
TTYPE7 = 'YPos ' / label for field 7
EXTNAME = 'StarInfo' / name of this binary table extension
Comments
Ascii file contains decorrelated magnitudes rather than fluxes.
In principle, the original fluxes can be recovered by using the timeinfo
data: seeing, airmass....
The assii file gives nothing on the flux variations other
than a ``variable flag''.
Should we add information about the flux variations?
Timeinfo:
In [9]: hdu[2].header
TTYPE1 = 'ImageId ' / label for field 1
TTYPE2 = 'DateTimeLocal' / label for field 2
TTYPE3 = 'DateTimeTU' / label for field 3
TTYPE4 = 'SiderealTime' / label for field 4
TTYPE5 = 'TStart ' / label for field 5
TTYPE6 = 'Expose ' / label for field 6
TTYPE7 = 'Nb0kGF ' / label for field 7
TTYPE8 = 'Nb0kPS ' / label for field 8
TTYPE9 = 'Fond ' / label for field 9
TTYPE10 = 'SigFond ' / label for field 10
TTYPE11 = 'PSF_SigmaX' / label for field 11
TTYPE12 = 'PSF_SigmaY' / label for field 12
TTYPE13 = 'PSF_Rho ' / label for field 13
TTYPE14 = 'Shift_DelX' / label for field 14
TTYPE15 = 'Shift_DelY' / label for field 15
TTYPE16 = 'Absorption' / label for field 16
TTYPE17 = 'Airmass ' / label for field 17
EXTNAME = 'TimeInfo' / name of this binary table extension
Comments
For the moment, there is no ascii file for this information
(one per ccd quarter). Should we construct them and put them at cds?
Note that the seeing, airmass information here allows us to
reverse the transformation flux(suivi)->mag(ascii)
Lightcurve
In [13]: hdu=pyfits.open('lm00703mrp5.fits')
In [15]: hdu[3].header
TTYPE1 = 'TStartDays' / label for field 1
TTYPE2 = 'Flux ' / label for field 2
TTYPE3 = 'Xi2 ' / label for field 3
TTYPE4 = 'Fond ' / label for field 4
TTYPE5 = 'ErrFlux ' / label for field 5
TTYPE6 = 'FluxB ' / label for field 6
TTYPE7 = 'S9Pix ' / label for field 7
TTYPE8 = 'PixMax ' / label for field 8
TTYPE9 = 'XPlusDelX' / label for field 9
TTYPE10 = 'YPlusDelY' / label for field 10
EXTNAME = 'LightCurve_1' / name of this binary table extension
Comments:
Should we add some of this information to the ascii lightcurves.
(chisq and S9pix might be interesting...)
As far as I know, none of the microlensing analyses have used
anything beyond the magnitude and magnitude error
3.b Réponse de Réza (7 septembre 2022)
3.c Complément de réponse par Jim (7 septembre 2022)
Au cas ou qq'un de vous a oublie ce qui est dans les fichiers ascii, voici
un exemple. On voit que le starinfo ascii est en tete du CDL ascii.
Jim
rich@dedippcc92:~/Anastasis$ head lm0017n.cat
# erosid Ra Dec MagR ErrMR XR YR MagB ErrMB XB YB VarFlag
lm0017n60 81.515090 -70.414630 19.329 0.367 915.40 426.56 19.492 0.355 885.72 456.37 0
lm0017n100 81.541040 -70.414120 19.631 0.489 840.97 429.08 20.034 0.536 811.26 458.76 0
lm0017n124 81.689850 -70.280720 20.333 0.641 386.88 1562.31 20.062 0.286 354.70 1591.10 0
lm0017n125 81.778720 -70.280860 18.905 0.314 130.72 1553.81 19.509 0.347 98.46 1582.14 0
lm0017n126 81.777690 -70.280720 20.150 0.978 133.67 1555.16 19.616 0.388 101.40 1583.49 0
lm0017n128 81.656250 -70.282070 18.740 0.298 484.02 1553.36 19.394 0.207 451.88 1582.32 0
lm0017n133 81.353200 -70.416460 18.535 0.226 1379.41 421.73 19.188 0.245 1349.90 452.41 0
lm0017n137 81.690450 -70.283550 19.842 0.380 385.74 1537.99 19.970 0.265 353.61 1566.78 0
lm0017n138 81.298390 -70.415740 20.071 0.453 1536.28 431.33 20.556 0.526 1506.81 462.30 0
rich@dedippcc92:~/Anastasis$ head lm0017n12068.time
# star: erosid MagR ErrMR XR YR MagB ErrMB XB YB
# lm0017n12068 18.415 0.126 633.33 1120.03 18.551 0.137 602.13 1149.27
#
# date MagR ErMagR MagB ErMagB
294.91026 18.181 0.090 18.306 0.085
296.91696 18.434 0.171 18.665 0.140
301.92747 18.484 0.196 18.640 0.174
315.89025 18.414 0.172 18.675 0.138
317.82385 18.354 0.163 18.436 0.090
317.88745 18.438 0.121 18.480 0.074
rich@dedippcc92:~/Anastasis$ grep lm0017n12068 lm0017n.cat
lm0017n12068 81.607940 -70.333010 18.415 0.126 633.33 1120.03 18.551 0.137 602.13 1149.27
qqs reponse/commentaires sur les question de Reza
(2) Une liste des étoiles , qui renvoie ensuite vers chaque courbe de lumière.
StarId , Position (ra, dec) , magnitude (or flux ?) Ref
StarId : je ne sais pas si les fichiers ascii attribue un numéro unique à chaque étoile ou pas ,
****** Dans les catalog ascii il n y a que erosid, par exemple lm0017n137
sinon, il faut construire un entier qui contiendra l’identification de cible/champ, numéro de CCD et quart de CCD, numéro d’étoile dans le
quart de CCD
****** je ne sais pas si un *numero* est vraiment necessaire si on a des erosid unique
Est-il utile d’indiquer la position des étoiles détectées sur l’image de référence (en unité de pixel ?)
****** c'est la position actuellement dans les .cat ascii (je pense....)
Faut-il rajouter une info du style mag-mean, mag-sigma , le long de la courbe de lumière, en plus d’un flag
caractérisant la variabilité ?
****** oui, ca serait utile, je pense
(3) Courbes de lumière (CdL)
Time, ImageId (renvoi vers la table image ou identifiant image) , (mag, mag-error)_Beros , (mag, mag-error)_Reros
****** Oui, la grande faiblaisse des CDL ascii c'est la manque du nom de l'image--il faut le chercher
dans un autre fichier en utilisant le ``date''
Je suis favorable d’enrichir ce qu’on met au CDS avec :
[ Flux , ErrFlux, Fond, Xi2, S9Pix + mag-uncorrected ] for Beros , Reros
mag-uncorrected = Flux converti en magnitude en utilisant la calibration photométrique absolu ,
histoire de faire le lien avec la magnitude des cdl qui ont été corrigé pour les bias avec seeing, airmass
****** C'est de l'info que nous n'avons jamais utilise dans la recherche de microlentille (a confimer, Marc, Patrick, Clarisse.....)
Enfin, question subsidiaire :
(4) Il y a peut-être une sélection faite pour faire les CdL ascii , par rapport à l’ensemble des étoiles dans les suivis.
****** Oui, par exemple on exige un mesure en rouge et bleu, je pense. A chiffre
Si OUI, est-ce que pour la table (2) - liste d’étoiles, on ne garde que les étoiles avec CdL où on met dans la table toutes
les étoiles présentes dans les fichiers de suivi.
****** Je ne pense pas qu'on a utilise les etoiles non-ascii pour les microlentilles. C'est dangereux
de mettre en ligne les choses qu'on n'a jamais etudie