Réunion VizieR 04/04/2018

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

Tiphaine

Photometry viewer : luminosités rest-frame reconnues ?

Le Photometry viewer n'est utilisé que pour les flux ou les magnitudes. D'après la réunion du 23 juin 2015, "l'unité doit nécessairement exprimer une densité spectrale de flux (par ex. Jy, ou bien W/m2/Angstroem)". Les luminosités ne sont donc pas prises en compte.

De plus, "un flux intégré (W/m2, ou Jy.km/s) ne peut pas être converti en densité de flux", le Photometry viewer ne fonctionnera pas dans ce cas. Les unités Jy/beam sont, quant à elles, ignorés automatiquement -- comme Gilles l'indique dans le CR de la semaine dernière

D'ailleurs, on note que "rest-frame" (ou "restframe" ou "rest frame") ne fait pas partie de la liste des mots-clefs qui excluent automatiquement la reconnaissance de filtres.
=> Gilles doit les rajouter.

Sur le même sujet, on se demandait le 28 mars 2017 s'il fallait ignorer les filtres lorsqu'il y avait le mot "aperture".
Un élément de réponse : pour le catalogue J/ApJ/830/51 (le fameux ZFOURGE), on avait pris les flux totaux, corrigés de l'aperture dont l'explication incluait "Total (aperture corrected) Ks-band flux" - j'aurais donc envie de dire non.

Il n'y a pas vraiment d'explication sur la manière d'identifier les filtres ou sur ce qu'est le Photometry viewer côté documentaliste à part au gré des différents CR qui répondent à des cas particuliers.
Néanmoins, j'avais déjà repris quelques info dans la doc des documentalistes sur la commande \vizFilter.

=> Il faudrait peut-être la compléter un peu ?
Notamment, il y a des informations contradictoires sur le fait d'ignorer ou non les filtres repris tels quels du 2MASS (et donc aussi SDSS, etc.)... Dans le CR du 8 mars 2016, on avait même noté que Gilles devait ajouter un flag "pour signaler les tables qui ne doivent pas être prises en compte dans le Photometry Viewer. On pourrait ainsi faire en sorte que tous les filtres soient reconnus ce qui permettrait des recherches par filtre, indépendamment du Photometry viewer." plutôt que d'ignorer systématiquement les filtres 2MASS avec la commande \vizFilter{ table }{ * [JHK]*mag }{ --- } (comme dit le 21 avril 2015)... Quid ?

Emmanuelle

J/ApJ/845/85 : des spectres en .sav sur Zenodo à récupérer ??

A priori, les fichiers .sav sont des extensions pour les utilisateurs d'IDL. On peut les convertir grâce à des modules Python (par exemple : http://python4astronomers.github.io/files/binaryfiles.html)...

=> Pierre est plutôt pour demander aux auteurs s'ils peuvent fournir les spectres en format FITS ou csv, ascii... Sinon, on laisse tomber.

J/ApJS/234/1 : des positions à recalculer en époque J2000 ? Epoque dans une colonne MJD en days, ne semble pas fonctionner ?

Dans la table 7, selon la note 7, les positions sont calculées à partir d'une époque moyenne (dans laquelle les mesures avec des grandes erreurs sur RA/DEC sont minorés). Plusieurs essai pour intégrer le "at epoch Epoch" ou "Ep=Epoch" se sont révélés infructueux avec des messages de type "abnormal Epoch value" et des positions qui ne collent pas du tout en sortie.

Normalement, la bonne écriture est bien "at epoch EpRA" sur le RA avec EpRA, la "mean epoch in RA" : exemple de J/A+A/597/A90 -- sauf que dans cet exemple l'époque est en yr et que là on a du MJD (=JD-2400000.5) d'après le label de la colonne...

=> Il s'agit probablement de l'unité qui devrait être en yr.
=> Tester en ajoutant une colonne convertie en decimal years.

On peut utiliser la commande jdate par exemple : jdate -yJ%012.7f MJD55326.38 avec %12.7f, le format de sortie. -y pour decimal year. "J" pour Julian. MJD ou JD devant la date MJD ou JD pour préciser le format d'entrée. On obtient en sortie J2010.3542231 (avec jdate -yJ%012.7f JD2455326.38, j'obtiens J2010.3528542 donc j'espère qu'il s'agit bien de MJD...)

J/ApJ/843/33 : des filtres pour le Photometry viewer ? + Problème de coo manquantes dans Saada (message "ERROR: fatal exception" en fin de push)

=> En fait, oublier les filtres SOFIA pour le Photometry viewer : dans ce catalogue, les flux ne sont pas facilement liables à un objet (donc une position).

=> Pour les positions manquantes, on ne peut pas vraiment utiliser les noms des targets pour avoir des coo (pas toujours des vrais noms). Elles manquent effectivement dans certains fichiers... Voir avec Gilles.

-- EmmanuellePerret - 2018-04-04