Réunion VizieR 06/10/2015

Présents : Marianne B., Sylvain G., Gilles L., Pierre O., François O., Emmanuelle P., Patricia V. et Mark Allen au début (merci pour la visite).

Pierre :

Problème du J/ApJ/797/15 ok?

Voir le CR du 15/09/2015 : il fallait voir si on pouvait retrouver des positions pour les objets donnés en Xpix, Ypix.
=> François a retrouvé un catalogue de référence (J/A+A/544/A73) qui permet de recalculer des positions pour Fornax 1 et 2 mais il n'existe rien pour Fornax 3 et 5.
=> Pierre regarde le catalogue (en local) pour voir si les positions calculées correspondent effectivement à des sources et s'il faut ajouter ces positions (ou écrire aux auteurs ?)
En broadcast avec image HST F555W sur Aladin, ce n'est pas forcément très convaincant...

Voir mise à jour de François dans CR du 15/09/2015 avec la commande xypos et le résultat qui donne un score de 30 donc normalement, de bonnes positions.

Problème du J/A+A/568/A126 (uniquement FTP), bien demandé en grand catalogue ?

=> Pierre vérifie.

Thomas a bien le catalogue dans la liste...

Question de Cécile sur le 6dF : objets avec qualité 0,1,2 et 6 ne sont pas dans la table ?

Effectivement, dans le catalogue VII/259, les objets de la table 6dfgs ne sont que de qualité 3,4 ou 9 (= table d'origine) alors que l'explication donne aussi les flags 0, 1, 2 et 6... Il faudrait ajouter les bornes dans la description du ReadMe pour éclaircir ce point (ou bien indiquer le nombre de sources correspondantes pour chaque flag dans l'explication).
Par contre, dans la table "spectra", on a des flags de qualité 1 à 6...

N.B. : bug d'affichage pour la table spectra sur le titre de la colonne FITS mais seulement dans vizier et pas en local...

Gilles :

Problème sur specfind signalé par Cécile

Il y avait des "\" en fin de ligne du programme, ce qui est possible sous Sybase mais pas du tout sous Postgres.
=> Gilles a corrigé.

Discussions pour le conseil scientifique

Il y sera question du nouveau service pour les données associées de type FITS que l'on expérimentera prochainement.
=> Pierre & Gilles discutent cet après-midi pour s'accorder sur la présentation pour le CS.

On ne sait pas encore à quel point et comment la charge de travail en sera modifiée.
Gilles a fait la liste des 300 catalogues contenant des fichiers FITS déjà dans VizieR qu'il faudra ajouter à la base.
=> Pierre regarde s'il peut en déduire un ordre de priorité pour l'ingestion de ces catalogues.
=> Gilles va commencer par en intégrer quelques uns, puis les documentalistes pourront s'y mettre aussi...

Patricia :

Suite à la demande de limite en taille pour des données de 100Go...

Voir CR du 25/08/2015 : un auteur avait demandé la limite en taille pour envoyer des données de 100Go (pas encore publiées). Après vérification par Pierre qui trouvait intéressant de récupérer les cubes de spectres et plusieurs échanges entre A&A et l'auteur, l'auteur a décidé de ne pas envoyer ses données au CDS (puisqu'elles seront disponibles sur 2 sites différents).

=> On peut toujours décider de les récupérer chez nous après publication mais ce n'est pas obligatoire puisque les données ne seront pas signalées comme étant au CDS dans le papier A&A.

Sylvain :

J/AJ/150/10 : unités, valeur en 9999/null, SB1/SB2 et liens vers paramètres d'orbites

1. Dans le papier, l'unité pour Lx est indiquée en erg/s avec x10^30^ en label. Est-ce que la colonne Unit du ReadMe est bien 10+23W dans ce cas (soit 10+30erg/s) ?
=> Oui !

2. Dans la table 3, il y a des valeurs nulles pour RV2 mais également 1 valeur à 9999.0000. Il n'y a pas d'explication particulière pour cette valeur dans le papier.
=> Transformation en null dans VizieR via la commande \vizSQL{ table3 }{set RV2=null where RV2=99990000} + Flag ajouté dans la table : "a=Indicates a RV2 value of 9999.0000 in the original table (set to null in VizieR only)", ok ?

=> Normalement, après vérification dans le papier qu'il n'y a pas d'explication particulière pour 99 ou null (ou autres valeurs nulles), on convertit toutes les valeurs N/A à null pour l'affichage dans VizieR mais sans ajouter de note.

N.B. : dans la requête \vizSQL , on ne peut mettre que des entiers dans la condition, les virgules ne sont pas prises en compte (d'où le 99990000)...

3. Dans la table 4, il y a des types indiqués SB1, SB2 (ou RR) mais parfois les paramètres orbitaux des objets indiqués de type SB2 se retrouvent dans la table des paramètres pour les single-lined binaries ?

=> Pour rappel, dans les types SB1, on ne voit qu'un seul spectre mais le paramètre de vitesse permet de dire qu'un autre élément est en orbite autour de l'objet principal tandis que dans le cas des SB2, 2 systèmes de raies sont visibles sur le même spectre. Dans les deux cas, des paramètres orbitaux sont mesurables.
Il y a sans doute des cas où on a pu classer un objet en SB2 car 2 raies étaient visibles mais sans pouvoir obtenir de mesures valides pour l'objet secondaire. C'est peut-être pour cela que l'objet se retrouve dans la table des single-lined ?

=> En faisant un \vizAddCount depuis la table 4 via le WOCS number sur les tables 5,6,7 et 8 de paramètres orbitaux, on règle le problème des liens.

J/AJ/150/42 : "spectroscopic distances based on absolute magnitude Mj" (en note) ou sur type spectral (dans le papier) ??

=> En fait la note est suffisamment claire : le type spectral (déterminé par spectroscopie ici) permet d'obtenir une magnitude absolue (quantité de photons que l'on doit recevoir dans l'absolu) et comme les auteurs ont aussi la magnitude apparente (quantité de photons réellement reçus) des objets, ils peuvent en déduire une distance. D'autant qu'ils ont une parallaxe pour certains objets qui leur permet de calibrer les magnitudes absolues.

Emmanuelle :

J/ApJS/213/5 : corrections sur 3 KIC de Cécile (avec des composantes B sur KOI) - corriger directement dans la table (+ note) ?

=> Ce serait mieux mais vérifier avec les auteurs que ce sont bien les KOI qui sont corrects et les prévenir que les KIC correspondants ne sont pas ceux donnés dans leur table...

J/ApJS/219/28 : table 3 des positions données en offset galactiques (arcmin) pour plusieurs régions (liste des centres donnés en note) ?

=> Le \vizposition ne permet pas de recalculer directement les positions. Il faudra les calculer via les programmes xypos (qui utilise ccd ), astropos ou ccd (voir des exemples pour astropos et ccd ici) et les lister dans une table.pos
Les positions sont calculables aussi directement via les formules :
b = b0 + oGLAT et l = l0+(oGLON/cos(b))
Attention, les centres sont données en degrés. On doit donc diviser les offsets (arcmin) par 60 pour obtenir les offsets (en degrés) dans la même unité que les centres.

Note pour Gilles & Pierre : xypos est disponible sous CVS.

J/ApJ/776/136 : Colonne SimbadName très grande (2 noms SDSS), possibilité d'imposer une valeur fixe à la colonne ?

=> Il vaut mieux laisser chaque browser décider de l'affichage...Le découpage se fait aux blancs donc en rajoutant un espace après le ";", ça devrait être mieux découpé dans ce cas.

Finalement, avec François, on a rajouté un petit programme qui ajoute une colonne pour chaque QSO (fg et bg) et fait un lien \vizSimbad sur les 2.

J/ApJ/805/3 : lien sur les obsID de Chandra mais certains numéros entre parenthèses, \sed possible pour convertir les parenthèses ?

=> Oui mais il faut écrire la commande correctement avec les [, ] pour indiquer parenthèse fermante ou ouvrante (sinon "()" n'est pas interprété et veut dire strictement "parenthèse ouvrante-fermante" sans rien dedans)...
ça donne :
\vizMore{ table1 }{ ObsID }{ \yMore{Display the Chandra log}{-source=B/chandra/chandra\&ObsID=,\sed{s/[()]//g}{@{ObsID}}}{@{}} }

J/ApJS/214/24 : 3D-HST+CANDELS catalog. Pas d'unités données - en faut-il pour les flux et radii ? Droit de récupération des données ?

1. Conversion via un fichier FITS où pas d'unité indiquée (ni dans la description de la table du papier). Les flux sont normalisés pour un AB zeropoint de 25.
Pour les AB magnitudes, le zeropoint flux est de 3631 Jy (voir Wikipedia AB magnitudes) ce qui donne une unité de 0,3631uJy à ajouter en colonne "Unit" du ReadMe.
Il n'y a pas d'unité pour le KRON_RADIUS issu de SExtractor. A priori le Circular aperture radius est en pixel.

2. Fichier indiqué disponible dans le papier mais e-mail demandé pour pouvoir l'obtenir... Droit de récupération dans VizieR ? => Ecrire un mail aux auteurs pour vérifier...

-- EmmanuellePerret - 2015-10-06