Réunion VizieR 24/03/2015

Présents : Marianne B., Sylvain G., François O., Pierre O., Emmanuelle P., Patricia V.

Pierre :

Les colonnes en rouge de "cross-match" (commande \vizAddXcount) pourraient peut-être porter à confusion...

Le terme "cross-match" peut être considéré comme une vraie cross-identification avec la source proposée (par exemple Cat. J/ApJ/768/37, "cross-match" avec FIRST dans 10" alors que le beam est plutôt autour de 5")...

=> On suggère de remplacer "cross-match" dans l'explication par : "Source(s) from {Cat.} within {rs}" pour enlever l'ambiguïté.

Lisibilité des graphes sans période serait meilleure avec la version widget

Par exemples, pour les Cat. J/A+A/576/A18 et J/A+A/570/A116. Le widget permet en effet un zoom direct sur les mesures alors qu'avec le .graph, il faut faire des cuts successifs par tatonnements...

Graphes :

Inversement, les graphes des Cat. J/ApJ/773/55 et J/AJ/149/95 sont illisibles avec le widget

- Nombreux filtres : il manque des couleurs ! La différenciation par symboles n'est pas évidente...
=> Il faudrait pouvoir cocher/décocher facilement les filtres donnés dans le cadre de la légende.
(G.L.) ceci peut se faire lorsque l'on affiche les options (en dessous du graphe)
=> Eventuellement, avoir un affichage par défaut de certains filtres.
(G.L) c'est possible en ajoutant dans le fichier .graph_sql une commande "set Filter=...." . voir doc: http://vizier.u-strasbg.fr/doc/viz/vizgraph.htx

- François a discuté avec Pierre F. d'un document qui a étudié comment maximiser la lisibilité des couleurs. Ce document
est accessible à http://www.sron.nl/~pault/colourschemes.pdf

- De plus, si on veut ajouter une période, il faut aller tout en bas de la page d'option ce qui n'est pas très pratique non plus... Ce serait pratique d'avoir la période au niveau des légendes pour tester celles qui sont données plus facilement ; ou au moins l'avoir en tout début de liste des options ou sous le graphe...

- Pour ces 2 graphes, bug sur les titres qui ne s'affichent pas (c'est le cas aussi pour le J/ApJ/756/173).

- Affichage des valeurs en "e+0" pour les magnitudes pas forcément très lisible non plus. Surtout pour le JD, "2.45e+6" n'est pas assez précis !

- Pour le J/AJ/149/95, Sylvain a dû faire 2 plots séparés pour y voir plus clair mais la comparaison IR/UV sur un même graphe serait plus intéressante.
N.B. : la période est donnée en heures pour ce graphe. La conversion en jour (0.8017) ne donne pas grand chose => c'est mieux sans mais on peut laisser la période convertie en jour dans le ReadMe comme on l'indique habituellement.

=> Pierre voit avec Thomas/Anne-Camille s'il peut négocier une meilleure ergonomie des widgets...

Sylvain :

J/AJ/149/26 : fichier en tar.gz qui n'est pas un tar ?

En fait il fallait faire unzip sur le fichier pour pouvoir le décompresser. (tar -xvzf renvoyait un message d'erreur : "tar: This does not look like a tar archive").

La commande file permet de voir qu'il s'agissait, en fait, d'un fichier Zip :

$ file aj502958figset1.tar.gz
aj502958figset1.tar.gz: Zip archive data, at least v2.0 to extract

J/AJ/148/122 : les formats dates et heures ne sont pas transformés en une seule colonne ?

En fait, ce sont les extensions .date et .time qui sont reconnues et regroupées (fonctionnent aussi avec .h .m, etc. Voir Conventions supplémentaires). Lorsqu'on en a plusieurs, il faut donc choisir d'écrire Obs1.date plutôt que Obs.date1 qui n'est plus reconnu... (Voir aussi CR du 24/02/2015).

François :

J/ApJ/772/13 : problème avec les formats de date qui avaient été regroupés à mauvais escient...

La date donnait le jour d'observation puis les heures et minutes (et non pas le jour/mois/année !!)
=> François a corrigé en Obs.date, format "YYYY-DDD", en rajoutant l'année dans la table (jour 88 = 2011/mar/29 ; le jour est bien traduit dans VizieR) ; suivi de Obs.h et Obs.m

J/ApJ/771/105 : SPECFIND est effectivement intéressant mais il faut tracer les points verts !!

Voir quelques explications sur le \SPECFIND dans la documentation. Lorsqu'on trace le SED depuis SPECFIND pour les sources radio, les points en rouge viennent de SPECFIND (Cat. VIII/85) et ce sont les points en vert qui viennent du catalogue que l'on regarde.
Dans l'exemple du .status :

%\vizLink{ tab }{SED}{SED}{\SPECFIND{-c=@{@pos},rs=30}{-query=asu_sed4 \
%   -source=@{@catab} @{===AT20G}}{@{}}}
%   {Plot the spectrum with SPECFIND (Vollmer et al. 2009, Cat. VIII/85)}

Il faut donc remplacer la 2è condition pour pouvoir retrouver le nom de l'objet ("Name" en l'occurrence) :

\vizLink{ table2 }{SED}{SED}{\SPECFIND{-c=@{@pos},rs=30}{-query=asu_sed4 \
   -source=@{@catab} @{===Name}}{@{}}}
   {Plot the spectrum with SPECFIND (Vollmer et al. 2009, Cat. VIII/85)}

J/MNRAS/438/2317 : Les noms de la table sont souvent faux (inversions, etc.) par rapport aux plate-mjd-fiber et redshifts donnés %ENDCOLOR%

=> François s'occupe de contacter les auteurs pour voir si on peut obtenir une table corrigée.

Le findsdss-sp interroge la DR12 par défaut

François a modifié le programme findsdss-sp qui permet de récupérer les identifiants SDSS via une liste de plate-mjd-fiber.
Par défaut, on récupère l'identificateur (JHHMMSS.ss+DDMMSS.s) de la DR12 (dernière version), les positions, le redshift spectro avec erreur et la classe de l'objet.

Par exemple :
cats@cdsarc(515) findsdss-sp 1604-53078-566 donne :

#...exec /usr/local/bin/find_gen findsdss-sp sdss-sp 1604-53078-566
#...aclient 130.79.129.161 1660 sdss-sp -sr -c 1604-53078-566
#...index=/r5/origcats/sdss-sp/mjd-pl-fibl.csv
#Positions of spectroscopic targets from SDSS-DRl
#...look -b 53078-1604-566, /r5/origcats/sdss-sp/mjd-pl-fibl.csv ...
J111354.66+124439.0 (R12); 168.477764+12.744180; 1604-53078-566 ; z=0.681245:0.000042; GALAXY BROADLINE

Emmanuelle :

J/ApJ/773/53 : une SN manquante dans la table de description de l'échantillon - relance auteur ?

La SN a été ajoutée dans la table pour "consistencies" mais ok pour la relance à l'auteur (après 1 mois sans résultat).

J/ApJ/776/67 : merge des 4 tables de prédictions de périodes rotationnelles en ajoutant soit la métallicité, soit le type d'objet dans les tables ?

=> Merge pas forcément intéressant. Laisser tel quel.

Autre question : l'UCD1 "PHYS_INERTIA-MOM" n'a pas de traduction en ucd1+. Dans les précédents résultats, on trouve "stat.variance" ce qui n'est pas correct !

Ecrire à Andrea pour lui demander d'ajouter un "phys.angMass" avec "Moment of inertia ou Angular mass".

-- EmmanuellePerret - 2015-03-24