Les données temporelles dans VizieR présentées par Ada - 10&11/07/2018

Présents: Marianne B., Gilles L., Ada N., Pierre O., Emmanuelle P., Tiphaine P.

Définition de "Time domain"

Slide 3: What is time domain in astronomy?

On veut la définition la plus large possible.

Une définition générale : il s'agit de "time domain" dès qu'on étudie quelque chose qui varie dans le temps et pour laquelle on a un suivi (follow-up).

L'exemple des GRBs qui déclenchent des follow-up sur différents instruments dès leur détection est parlant mais il y a beaucoup d'autres exemples.

Exemples concrets de "Time domain"

Cela peut être sur une durée très longue. Par exemple : suivi de taches solaires sur 400 ans ! (slide 4)

Les Céphéides (slide 5) sont très importantes car leurs périodes permettent de calculer les distances.

Les light curves et spectres de SNe (slide 6) permettent de définir les compositions chimiques et donc les types de SNe.

Les binaires vont permettre de déterminer des masses, mesures qui n'est pas facile à obtenir et
Le suivi des variables cataclysmiques (binaires dont l'une des étoiles est une WD qui accrète de la matière de l'étoile secondaire) permet de déterminer des moments angulaires. (slide 7)

La mission DASCH (Digital Access to a Sky Century @ Harvard) a scanné 500,000 plaques photos prises entre 1885 et 1995. (slide 9)

Les suivis sont particulièrement intéressant lorsqu'on croise les longueurs d'onde et les échelles de temps peuvent varier de la secondes (millisecond pulsars) à plusieurs centaines d'années. (slide 10)

Slide 11 : illustration des différentes échelles de temps pour différents types d'objets :

On voit des exemples de variations de luminosité dans le temps mais ce n'est pas seulement la luminosité qui varie. Il peut y avoir des variations d'orbites (par exemple tous les mouvements observés dans le centre Galactique) ou de positions (planètes...)

La définition du flare est précise : la luminosité suit une loi exponentielle (elle augmente très rapidement) puis diminue progressivement. Cette variation décrit le phénomène physique (variation luminosité) mais il peut y avoir différentes causes à ce processus : il n'y a pas que des flares pour le Soleil. Les étoiles M ont aussi des flares (d'amplitude moindre) qui sont dus au courant magnétique (lorsqu'il se tord, le champs magnétique peut s'interrompre ce qui crée un flare).

Définition des AGN (active galactic nuclei) : au centre des galaxies se trouve un noyau actif particulièrement brillant. Les quasars (QSOs=quasi-stellar objects) sont des objets qui apparaissent compacts (comme si une galaxie n'avait conservé que son noyau) -- ils peuvent être confondus avec des étoiles bleues. Selon l'angle d'observation du quasar, on a différent types de quasars : on observe des raies d'émission très étroites si on observe le QSO par le côté du disque (edge-on) alors que les raies sont très larges si on l'observe sur le dessus (face-on). Ces derniers sont des quasars de type II et leurs raies d'émission peuvent être perturbées par des nuages de poussière. On note que même les QSOs peuvent varier dans le temps si on les observe assez longtemps (ils changent de type).

Le Sloan qui obtient des LCs et des spectres depuis plusieurs années permet déjà de voir les variations dans l'émission des raies d'objets tels que les AGN. Voir les études de "reverberation mapping".

Définition de transient : il s'agit d'une source qui change brutalement de comportement par rapport à un comportement normal. Terme très général pour les sources dont on ne connait pas l'origine.

Exemples de mission "Time domain"

Slide 12: missions dédiées pout le suivi des transients

Illustration depuis les missions passées (CRTS, télescope de 2m) jusqu'aux présentes (iPTF, SDSS et Pan-STARRS), voire à peine sorties (ZTF) et futures (LSST, télescope de 10m).
Ces missions observent le ciel en permanence et renvoient des quantités impressionnantes de données (ZTF => 1 million de transits par nuit ; LSST en prévoit 10 millions).
Des LCs sont produites et des spectres directement ou indirectement (via déclenchement de follow-up pour les objets intéressants).
Tous les 3 jours, on obtient une image du ciel (field of view de l'instrument) - celles-ci sont comparables pour détecter les changements (transits).

Définition du temps

Slide 14 : qu'est-ce que le temps et comment le mesure-t-on ?

Le Jet Propulsion Laboratory (JPL) de la NASA fournit les éphémérides et les conversions nécessaires aux astronomes.
Des librairies pour convertir les temps existent déjà - voir astropy.

L'article de Rots et al. 2015A&A...574A..36R définit précisément les systèmes de temps (slide 15). Ils seront repris plus loin pour les métadonnées à définir dans VizieR.

Le but : comparer les manip'

Pour comparer les données, il faut savoir si les observations sont similaires. On a donc besoin de définir un système référentiel unique dans lequel les observations peuvent être décrites.

Slide 16: questions nécessaires pour définir un système référentiel :

• Where
• How
• Offsets in data (pour les GRBs, observations après trigger par ex.)
• Format (JD, ISO...)
• Units (pour JD = days)

Les données temporelles actuellement dans VizieR

Pour l'instant, les données sont très hétérogènes (avec un mélange du format/unités/système) et principalement textuelles (slide 17).

Les UCDs sont parfois incorrects : time.period qui devrait être autre chose.

=> Jusqu'à présent on utilisait les UCD1 assez limités en terme de date : TIME_DATE , TIME_EPOCH mais aussi de temps :
Les plus utilisés :TIME_EXPTIME, TIME_INTERVAL/TIME_DELAY, TIME_PHASE, TIME_PERIOD, TIME_DIFF, TIME_MISC mais on a aussi :
TIME_DP/DT, TIME_EVOLUTION, TIME_LIMIT, TIME_RESOLUTION, TIME_SCALE, TIME_ZONE, ORBIT_P-ASTRON_DATE...
A voir pour ce qui existe déjà dans VizieR au niveau de la conversion automatique UCD1 vs ucd1+...

Les ucd1+ permettent, par contre, de combiner l'indication de temps et le phénomène physique ce qui serait intéressant (temps + éclipse par exemple).

Mireille et Seb ont déjà travaillé avec Ada sur l'ajout d'ucd1+ pour le domaine temporel (passe par l'IVOA). Possibilité d'en ajouter de nouveaux mais a priori il y a déjà ce qu'il faut. Par contre, attribution des UCDs pas si évidente : l'UCD builder ne fournit pas toujours de réponse et la commande setUCD non plus...

Les tables META ajoutées pour VizieR

Un peu à la manière des filtres, Ada, Gilles et Pierre ont travaillé sur l'ajout de tables META pour extraire les données temporelles des catalogues.

Il y a 8 tables META pour le temps (slide 18) basées sur l'article de Rots+, 2015 PDF

1. Slide 19: Table METAtimeScaleRef = l'échelle du référentiel (how)

Le table 2 de Rost+, 2015 est reprise pour donner les définitions des différentes échelles de temps.

Lorsque TT, TAI, etc. ne sont pas connus, une incertitude par défaut sera attribuée au catalogue.

2. Slide 20: Table METAtimeFrameRef = le cadre du référentiel (where)

Les différentes localisations (table 3 de Rots+ 2015) - très important à définir ! (on fait néanmoins confiance aux observatoires pour faire les conversions qu'il faut en TOPOCENTER).

3. Slide 21: Table METAtimeRepstRef = la représentation du référentiel (format)

On a MJD (= JD-2400000.5)
JD (non transformés - voir plus loin si valeur retranchée => offset)
ISO pour les dates YYYY-MM-DDThh:mm:ss

On ne pourra pas faire grand chose du CUSTOM (différent de UNKNOWN. Pour CUSTOM : utilisation d'un système propre à l'auteur alors que UNKNOWN = non renseigné).

Le format devrait permettre de définir les unités. Par exemple, JD => d.

Note : HJD (Heliocentric (défini en point 2) + JD) vs BJD (Barycentric JD => barycentre du système solaire) donne une différence de l'ordre de la seconde... Par contre entre Geocenter ou une autre planète, la différence est de taille !

=> A voir pour inclure le référentiel dans les bonnes pratiques pour les auteurs.

4. Slide 22: Table METAtimeSystem = le système complet avec les IDs internes pour les tables précédentes

En plus des IDs internes pour les tables précédentes (scale_id et frame_id), on a une time_systematic_err.

Pour cette valeur, on voit que si scale (point 1) et cadre (point 2) sont manquants, une erreur par défaut de 1000s est attribuée au catalogue (seulement 100s si 1 manquant).

5. Slide 23: Table METAtimeCol donne les différents identifiants META + offsets et temps d'intégration (Offsets)

Ici on reprend l'ID interne time_syst (point 4) et time_rep (point 3), on a l'identifiant interne du catalogue (catid), des tables et des colonnes (colid).

Ce qui est ajouté : le time_offset et time_uncertainty.

Si une valeur est retranchée au JD, par exemple, ont peut donner la valeur de l'offset.

Exemple de time_offset dans la table : pour 1345 (Gaia DR2), 2,455,200 a été enlevé au JD.

Dans la table, on voit que pour 1345 (Gaia DR2), on a 3 lignes car 3 colid différents. C'est parce qu'il y a 3 colonnes représentant le temps : TimeG, TimeRP et TimeBP dans Gaia qui sont les temps pour les différentes bandes G, RP et BP.

Le time_uncertainty correspond au temps d'intégration.

Ici : 44 = temps de transit d'une source pour traverser le champs focal dans la bande G (45s) -- les focales des autres bandes sont plus étroites donc temps plus court de 5s.

6. Slide 24 : Table METAtimeRel : donne les relations entre la colonne de temps et les valeurs que le temps concerne

Ici pour I/345, chaque temps et lié à 2 valeurs. Par exemple, timeG se relie à FG (col. 4) et Gmag (col. 7) et time_rel_id donne l'identificateur "id" de la table précédente, METAtimeCol.

=> Gilles doit faire un hyperlien pour retourner sur cette table METAtimeCol à partir de time_rel_id.

On pourrait faire un label du style t_Gmag pour avoir un lien automatique (comme les e_Gmag) mais dans cet exemple de Gaia, on voit que cela ne fonctionne pas s'il y a plusieurs valeurs liées au temps.

Il n'y a pas de relation définie pour le catalogue 18060052 car il y a un .graph_sql qui doit permettre de retrouver les relations automatiquement.

On pourrait peut-être retrouver des relations automatiquement en cherchant les mag/flux, RV mais toutes les colonnes d'une table ne sont pas automatiquement liées au temps (par ex. il peut y avoir des coordonnées qui viennent d'un autre papier, etc.)

7. Slide 25: Table METAtimeSys est le système lisible par un humain...

Donne les valeurs en clair (et pas les IDs internes) pour Scale (point 1), frame (point 2) etc.

8. Slides 26 et 27: Table METAtime est la table générale qui reprend tout

On a donc besoin de définir 5 choses pour avoir un système complet :

- l'échelle du référentiel (UT, TAI, etc.) qui sera indexé dans METAtimeScaleRef (point 1)
- la localisation (HELIOCENTRIC, BARYCENTER, etc.) , indexé dans METAtimeFrameRef (point 2)
- la représentation du temps (JD, ISO, etc.) , indexé dans METAtimeRepstRef (point 3)
- le centre pour les offsets , indexé dans METAtimeCol (point 5)
- les liens entre la/les colonne(s) de temps et les valeurs, indexé dans METAtimeRel (point 6)

=> Il faudra voir avec Gilles comment on peut automatiser une partie de ces choses et faire une vérification des métadonnées qui sont archivées (vérification lors du 2v comme pour les filtres, commande dans le .status ... ?).

Et la suite ?

Slide 28: Conclusion

Les données temporelles sont une priorité pour l'IVOA et les missions ; l'effort supplémentaire à investir est à diagnostiquer mais il est important de voir comment faire au mieux pour extraire ces données.

=> La prochaine étape : choix de quelques catalogues concrets (Sloan, Stripe 82, PS1, autres petits catalogues) pour voir ce qu'on en extrait (réunions prévues le lundi 16/07, 14h + mardi 24/07).

=> Les exemples définis : ExemplesTime

Présentation des tMOC

Dans sa version béta, Aladin a déjà intégré une partie des données temporelles pour créer des MOC temporels. On retrouve la couverture temporelle des catalogues mais pour l'instant, on affiche juste les durées d'observation sans pouvoir extraire les données qui vont avec...

-- EmmanuellePerret - 2018-07-11