Réunion VizieR 12/09/2018

Présents: Marianne B., Gilles L., Pierre O., Emmanuelle P., Tiphaine P., Patricia V.

Patricia

Bug sur le catalogue VVV (II/348 ou II/337?)

Le lien "Full" se fait par recno (et pas par coo comme pour Gaia par exemple) mais pour certains recno, le lien pointe systématiquement sur le recno 99999...

=> Gilles est en train de résoudre le problème.

GL: II/348 est corrige

Tiphaine

J/AJ/154/188/table4 : le widget du graphe donne des JD arrondis à 2 décimales alors qu'il y en a 5 dans la table ?

=> Il n'y a pas de raison que ces valeurs soient tronquées...
=> Gilles regarde ce qui se passe.

J/AJ/154/260 (et J/AJ/154/263) : les \viztimeRel font planter le 2v ?

Les \viztime ont l'air de fonctionner mais l'ajout des \viztimeRel font effectivement planter le programme.

=> Gilles regarde.

Petit point sur les tests fait pour l'intégration des données temporelles :

La doc VizieR a été mise à jour par Gilles : http://cdsarc.u-strasbg.fr/doc/viz/#viztime

Pour l'instant, les documentalistes peuvent renseigner les champs :

• system= : Par exemple, pour J/ApJ/851/L27, observations XMM => \viztime{ table1 }{ JD }{system=XMM}

• frame= position de référence telle que barycenter, heliocenter...

Note : Heliocenter devrait être détecté automatiquement désormais pour les cas du HJD, ou JD + Heliocentric dans la description ; Barycenter dans BJD était déjà reconnu automatiquement ; et Gilles est en train de faire la modif pour que MHJD soit également reconnu (MJD + Heliocentric)

• scale= : TT, UTC, etc.

Note : c'est différent de "ISO" qui est sensé être reconnu automatiquement pour le "time_representation" (qui prend les valeurs MJD, JD, ISO ou CUSTOMIZED) et que l'on ne peut pas mettre à jour via le .status.

GL: en fait si, on peut ajouter la representation dans le .status - mais ce n'est pas dans la documentation..
l'idee est que 2v devrait trouver le format(=representation) de maniere automatique... travail en cours pour amelioration!

Dans le cas de J/ApJ/851/L27 où il y a une date ISO au format YYYY-MM-DDThh:mm:ss avec l'unité "datime" ["date" étant réservée pour les formats Y/M/D], la représentation n'est pas encore reconnue automatiquement. Les cas où le label est Obs.date (unité= "Y/M/D" ou "date") + Obs.time (unité = "h:m:s") [écriture classique dans le ReadMe qui permet de faire une conversion YYYY-MM-DDThh:mm:ss dans VizieR avec stockage de la valeur en seconde] ne sont pas encore pris en compte par Gilles non plus. Dans ce cas, time_representation est assigné à CUSTOMIZED.

GL: ces points ont ete ameliores : ce devrait etre mieux

=> Il faut remonter l'info à Gilles pour qu'il puisse régler les différents cas de détection automatique.

• offset= : Par exemple, pour J/AJ/154/260, \viztime{ table4 }{ JD }{offset=2400000}

Note 1 : normalement si on écrit JD-2400000 en explication, le programme devrait détecter l'offset automatiquement...

GL: la detection automatique commence toujours par le nom de la colonne

Note 2 : Pour les offsets sur les MJD, si MJD est bien décrit en "time_representation" (reconnaissance automatique), l'offset 2400000.5 est déjà pris en compte dans la définition du MJD. Seul, un offset supplémentaire doit être indiqué -- par exemple : MJD-52000 donnerait un offset=52000 avec time_representation = MJD dans la table METAtime.

GL: la detection automatique de colonne temporelle: basée sur les 2 tests suivants (qui doivent tous 2 etre satisfait)

• detection par le nom de colonne: JD , ou une liste definie ("date", "time", "epoch")
• test de coherence sur les unites: "d", "datime", "Y:M:D", ...

Rechercher de l'offset: n'est automatique (recherche dans la description) que pour les noms de colonnes JD, MJD, BJD, HJD, MBJD ou HMJD

• uncertainty= : correspond au "time_uncertainty" de la table METAtime, il s'agit d'une constante qui définie l'erreur de mesure générale d'un Survey (par exemple, 44s pour Gaia). [Donc rien à voir avec l'erreur systématique (col. "time_systematic_err") qui est attribuée automatiquement à un système lorsqu'on ne connaît pas le frame ou le scale).

=> Pierre voit avec Ada s'il faudrait ajouter le max des e_JD (ex du cat. J/AJ/154/260) dans cette "uncertainty". (Possibilité de détection automatique des colonnes e_...).

• flag= : est encore incertain... Peut-être qu'il servira pour min/max - à moins qu'on ajoute une colonne indexée supplémentaire pour avoir un intervalle du temps d'observation ?

La syntaxe du \viztimeRel est bien \viztimeRel{ table }{ column }{ table }{ column } - exemple typique dans Gaia. Il sert à relier les colonnes de temps à leurs magnitudes respectives quand il y en a plusieurs (cas des HJD-B, HJD-V, etc.)

Lors du 2v , lorsqu'une colonne de temps est détecté automatiquement, on nous demande confirmation, par exemple :

Time Column detected (Date): system=UNKNOWN, offset=-1.000000 rep=CUSTOMIZED
    Observation Date (YYYY-MM-DDThh:mm:ss)
CONFIRM:Time ? [N]

On peut choisir d'ignorer cette colonne dans le .status afin que les futures ingestions du même catalogue ne soient pas interrompues par une question si on ne veut pas de cette colonne. La syntaxe est \viztime{table*}{Date}{---} (voir Mail de Gilles du 10 septembre).

Ou bien on peut préciser les champs ci-dessus dans le \viztime du .status pour compléter les infos.
Quand on ajoute un \viztime , on a l'info suivante lors du 2v (attention ça va très vite, il faut des yeux bioniques ou alors rechercher le mot-clef "Detect Time config") dans la liste des messages :

Detect Time config: system=XMM, offset=-1.000000, uncertainty=-1.000000, time: scale=NULL, frame=NULL

On peut éventuellement vérifier que tout s'est bien passé pour son catalogue dans la table METAtime (sur cdsarc), en recherchant son catid.

Emmanuelle

J/ApJS/235/41 : suite des T0 bizarres (CR du 5 septembre) ?

L'auteur a répondu mais insiste pour laisser 9453.419. Si on convertit 2409453.419 en UT date, on obtient le 3 octobre 1884, ce qui parait peu probable. En fait, la valeur est prise telle quelle dans J/A+A/563/A120 ou on a un "RJD"="reduced JD ?"...

=> Patricia pense corriger pour JD-2440000

Emmanuelle : sauf que ce n'est pas possible non plus car il y a des valeurs à 54338.40574 dans cette table et que si je fais +2440000, j'obtiens une date UT = 1 mars 2117... !!

Vu avec Patricia : en fait, dans le papier, ils vont chercher les minima et maxima dans la littérature (sur 125 ans d'observation...) donc c'est bien du JD-2400000 et c'est bien une observation de 1884...

J/ApJS/212/18 : ajout des spectres et des images FITS suite à une demande faite à Mark à l'IAU

=> OK pour les imagettes + Plot en modifiant l'axe des Y pour avoir lambda*Flux qui correspond plus à l'image (modification en direct live depuis la salle de réunion).

=> A voir avec Gilles pour l'insertion des images FITS dans Saada - pour l'instant, 2 listes ne passent pas + voir si possibilité d'ajouter différentes colonnes avec les différentes images par objet.

EP : les 2 listes ne passaient pas car certains fichiers de la liste n'étaient pas retrouvés... Soit non existant, soit écrit différemment... Dans ce cas le putimg s'arrête et puis c'est tout.

On a laissé tomber la récupération du nom de l'objet pour Saada (trop compliqué à retrouver avec le sous-sous-répertoire par nom d'objet)...

-- EmmanuellePerret - 2018-09-12