Réunion VizieR 29/08/2017

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

Pierre

Nouvel outil de validation

En place pour les documentalistes (http://cdsarc.u-strasbg.fr/follow/index.gml).
Exceptés :

• Les catalogues "err" entrés lors de l'installation hier après-midi. => Mettre en "Ready" ceux de Patricia ; Sylvain relance son AJ dont le 2v avait été interrompu (status "err" normal dans ce cas).
• Les catalogues "Test" vont passer en "Ready". Aux documentalistes de voir si certains sont encore en cours de modification.

Une fois en "Ready", Pierre et Caroline auront accès aux boutons de validation. (Sinon, Gilles passera pour voir).

Gilles doit aussi passer chez Patricia dont l'interface n'affiche rien...

B/gcvs

Patricia a adapté le petit programme de François (awk/bash) qui permet de :

• Récupérer les fichiers qui peuvent être modifiés d'une version à une autre dans un répertoire temporaire
• Les modifier si besoin pour avoir la bonne description correspondante dans le ReadMe
• Les basculer vers un répertoire New où les tests peuvent être faits pour voir si tout va bien.

Les fichiers qui sont susceptibles d'être modifiés sont au nombre de 9 (ou 8 ?) :

• crossid.dat
• nsv_* (catalogue, remarques et refs)
• gcvs_* (cat, rem, refs aussi)
• refs.dat

Les fichiers evs_* n'ont pas changé depuis 2012.

Gilles voudrait savoir ce qui change exactement dans les fichiers qui sont mis à jour.

=> Patricia et Gilles peuvent voir ensemble comment cela s'intègre (ou pas) dans le pipeline automatique (programme en Python, fichiers ReadMe et .Summary des précédentes versions à conserver, etc.).

J/A+A/549/A109 : question de Pierre F. sur compte-question pour des signes de pmRA inversés dans la table 3

=> Emmanuelle corrige directement et écrit à l'auteur - relance aussi pour les tables qui n'ont jamais été envoyées...On ne sait jamais !

OK, c'est fait.

J/ApJ/830/51 (Redmine #2537): il restait des questions sur les filtres pour Pierre...

=> Principalement, ce sont les filtres de l'instrument FourStar et quelques uns pour Subaru qu'il faudrait entrer dans METAfilter (http://cds.u-strasbg.fr/twiki/bin/view/Documentaliste/VizierDocumentaliste/ListeFiltres - fin du tableau) mais je ne sais pas trop ce qu'il faut entrer comme lambda0 (um), dlambda0 (um) et Fmag0 (Jy) dans l'outil d'ajout des filtres de Gilles (http://cdsarc.u-strasbg.fr/follow/filters.gml).
On avait dit que dlambda = lambda/23 pour les filtres Subaru déjà.
Dans mon catalogue, j'ai lambda_C_, FWHM (qui n'est pas le dlambda, cf. pour Subaru) et un Zeropoint en AB mag (=> conversion pour avoir Fmag0 en Jy ?)

Je reprends aussi deux questions posées sur Redmine (http://cdsbug.u-strasbg.fr/redmine/issues/2537#note-22) :
Pour FourStar, il y a aussi 2 narrow-band (118 et 209), est-ce qu'il faut les ajouter aussi dans le METAfilter et les prendre pour le Photometry Viewer ?
Sinon, j'ai quelquefois de légères différences entre les lambda données dans le papier et celles correspondant aux instruments dans METAfilter.
Par exemple pour zf_uds, j'ai un Fi (Subaru/Suprime-Cam i-band) donné à 0.7656 dans le papier vs 0.7591 dans METAfilter... Est-ce que c'est une différence importante et sinon à partir de quand la différence peut devenir importante ?

Enfin pour cette ref., je l'avais mise publique mais il faut que je confirme à l'auteur que tu l'as bien validée pour qu'elle puisse mettre le lien vers VizieR sur son site. Tu dois avoir un mail pour ça datant du 3 août (cf. http://cdsbug.u-strasbg.fr/redmine/issues/2537#note-23).

Sylvain

J/AJ/153/174 : la date (UT), en format A12 avec des secondes à 1 décimale dans la table FTP, est arrondie à la seconde sans décimale dans VizieR. Important ?

Note pratique : en choisisant l'onglet "Browse" dans VizieR, on affiche facilement la table ASCII du FTP en choisissant ".txt"...

L'arrondi n'est pas grave dans le cas de ce catalogue, les temps d'observations sont plutôt de l'ordre de la minute...

Par contre, cela pourrait être gênant dans d'autres cas. Pour les gamma-rays par exemple... ?

Gilles a déjà eu ce problème pour les logs du CFHT dont les dates d'observations sont données au dixième de seconde.

Pierre demande s'il y a une limite sur le stockage de la date en MJD également ?

=> Gilles regarde.

GL: c'est ok; la precision des valeurs des colonnes MJD dependent du type de donnéées stockees en bases:
ex catalogue J/AJ/153/174: table2.MJD0 est stocke en entier (dans a la seconde), table3.MJD en flotant F11.5 est stocke en flotant double precision.

=> A voir si on peut faire en sorte que des dates plus précises soient conservées dans VizieR.

J/AJ/153/71 : Le \vizAddCount (col. OCat) ne donne pas le bon nombre de liens retrouvés dans les catalogues interrogés ?

Lien fait sur les KOIs.

1. Même si le catalogue d'origine donne des KOI en chiffre entier (correspondant à l'étoile) ; le résultat retourne aussi les KOI en décimales (les planètes). (Il y a une conversion par le programme du float en chiffre entier >=). Ce qui peut être pratique ! Par contre, le comptage du Addcount ne donne que le nombre de résultats correspondant au KOI entier.

2. Dans le cas de ce catalogue, on traite plutôt dans la table des étoiles hôtes. On peut donc faire directement le lien via les KIC (qui sont toujours des nombres entiers). Généralement, lorsque seul le KOI est donné dans un catalogue, on ajoute son équivalent KIC dans VizieR pour retrouver les positions qui vont avec...

=> Changement fait en direct live !

Pour rappel : KIC = Kepler Input Catalog (catalogue V/133 dans VizieR) : liste les étoiles de Kepler. KOI = Kepler Object of Interest : correspond également aux étoiles et ont normalement un et un seul KIC correspondant. Les KOI au format N.NN, sont les planètes candidates liées à l'étoile N (+ numéros des planètes dans l'ordre des découvertes).

Emmanuelle

J/ApJS/230/17 : dans la première table, les positions ICRS gagnent une décimale de plus en précision alors que les autres tables, non... ?

Les positions sont calculées à partir des positions galactiques données dans le nom. Dans les 3 tables, le format du nom est GLL.lll+B.bbb mais dans la première table, les positions ICRS calculées donnent 4 décimales alors qu'elles en donnent seulement 3 pour les autres... Du coup, la précision en sexagésimale n'est pas la même pour la première table et les deux autres. Bizarre ?

=> Voir avec Gilles.

-- EmmanuellePerret - 2017-08-29