Réunion VizieR 17/02/2015

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

Marianne :

Mihaela a eu besoin d'interroger VizieR par acronyme...

La recherche d'un acronyme entre crochets ne fonctionne pas car les crochets sont compris comme contenant une expression régulière et la recherche donne donc des résultats qui n'ont rien à voir avec l'acronyme.
De plus, en vérifiant le stockage d'un acronyme dans la base via la table METAcro, on note que les crochets ne sont pas conservés (sans doute car ils créent quelques problèmes...)

La recherche fonctionne en supprimant les crochets, dans le cas où l'acronyme a été indiqué dans le \cUsualName du .status (cf. CR du 03/02/2015 pour l'effet du \cUsualName sur l'interrogation VizieR). C'est le cas si l'acronyme existait déjà au moment où la référence est entrée dans VizieR ET si l'acronyme a été spécialement créé pour cette référence (le \cUsualName n'est pas indiqué si ce sont des objets ré-étudiés).

=> Pierre propose que Gilles ajoute une ligne à la documentation d'aide de VizieR (http://vizier.u-strasbg.fr/vizier/vizHelp/1.htx#source) dans le paragraphe sur le "target input" pour indiquer que la recherche par acronyme doit se faire sans les crochets (qui indiquent, par ailleurs, une expression régulière).

=> Une autre possibilité d'interrogation de VizieR se fait via TAPVizieR (http://tapvizier.u-strasbg.fr/adql/) par requêtes ADQL (~SQL).
Gilles propose de faire une petite démonstration des possibilités de ces requêtes aux documentalistes ; qui n'attendent que ça.

=>De plus, pour les cas où l'acronyme est créé après insertion de la référence dans VizieR, il faut pour l'instant recharger à chaque fois la référence via le 2v pour que le \cUsualName soit pris en compte.
François se demande s'il n'existe pas une commande qui permettrait de recharger seulement les métadonnées sans avoir à recharger tout le catalogue ?
Cela permettrait à Marianne d'ajouter plus facilement les acronymes pour les catalogues déjà en ligne.

-> Petit complément (Vu avec François) : Il s'agissait de l'option -keep, mais elle ne semble pas marcher correctement notamment quand le catalogue concerné contient des tables fusionnées. Il semble donc préférable de simplement faire un 2v. (Marianne)

Enfin, on aimerait avoir la liste des acronymes liés à un catalogue qui devraient avoir un \cUsualName remplit dans VizieR pour vérifier que le nombre est correct mais ce n'est pas si simple :
actuellement il y a 4015 acronymes dans VizieR (cf. table METAcro) contre 22106 dans le dictionnaire mais même pour les acronymes liés à des catalogues, le \cUsualName n'est pas utile s'il ne vient pas de la référence d'origine... Il faudrait donc pouvoir réduire la liste des acronymes liés à des catalogues dans le dictionnaire et qui ont aussi un numéro séquentiel dans VizieR, par exemple, pour le cas des acronymes basés sur un numéro séquentiel...

Gilles :

Instauration du pool de connexions ouvertes semble efficace contre les lenteurs VizieR

Un pool de connexions déjà ouvertes (150) a été créé par Gilles ce qui fait gagner du temps de connexion aux catalogues. Cela semble efficace et est encore améliorable avec l'installation d'un cache global.
Actuellement environ ~500,000 requêtes/jour sur VizieR, à voir si le nombre de requêtes augmentait brusquement.

Pierre demande si on peut envisager la mise en mémoire de tous les "petits" catalogues VizieR (~100Go actuellement). Il faudrait revoir pas mal de choses dans ce cas...

Par ailleurs, la machine vizDB va changer prochainement avec une RAM (radom access memory = mémoire vive) augmentée (mais pas avec SSD (solid-state drive) car le disque s'abîme s'il y a de nombreuses réécritures ce qui est le cas pour VizieR).

A propos de la documentation d'aide pour VizieR

Il y a eu une réunion récente concernant les documentations pour les utilisateurs concernant les bases du CDS (si j'ai bien compris ?). Pour l'instant, Gilles est le seul à avoir la main sur la page d'aide mais il se demande si d'autres personnes ne pourraient pas participer. D'ailleurs, une des conclusions de cette réunion est la création d'une page F.A.Q. pour VizieR, il faudrait donc réfléchir aux questions que les utilisateurs peuvent avoir lorsqu'ils interrogent VizieR ou soumettent des données.

=> Pierre pense qu'on peut utiliser le compte-question pour voir ce qui ressort fréquemment. François et Gilles pensent que ça risque d'être compliqué de remonter dans le temps les échanges du compte-question et qu'il s'agit surtout de bugs...

Patricia en profite pour rappeler qu'il n'y a toujours pas d'aide pour les auteurs à propos des fichiers FITS. (Question qui lui est fréquemment posée : que dois-je envoyer et avec quelle description car le ReadMe concerne des tables ce qui n'est pas le cas en général pour les fichiers FITS de spectres, images, datacube, parfois 4D...)

=> Pierre va rédiger un petit paragraphe d'aide pour les auteurs qui ont ce genre de données.
Des exemples de ce qu'il y a déjà dans VizieR peuvent servir : page http://vizier.u-strasbg.fr/vizier//cats/M.htx avec les catalogues les plus récents dans les différentes catégories cubes, images, spectres, timeSeries...
Il faudrait une liste des mots-clefs les plus importants (basés sur ObsCore) qui devraient se retrouver dans les Header des fichiers FITS.
Et préciser qu'une ligne ne devrait pas contenir l'ensemble des spectres de tous les objets (voir plus bas Cat. J/A+A/570/A2).

Submit mis en ligne à la fin du mois

Gilles en profite pour prévenir que la page "submit" pour les FITS sera mise en ligne vers la fin du mois. L'URL de la page sera envoyée aux testeurs.

Corrections SIMBAD vers VizieR et vice-versa...

Soizick réfléchit à un moyen pour que les corrections faites dans SIMBAD soit systématiquement signalées à l'équipe VizieR via l'envoi d'un e-mail automatique (?)
Effectivement les corrections de SIMBAD peuvent avoir des conséquences pour les catalogues VizieR à mettre à jour (voire des conséquences pour le dictionnaire). C'est aussi vrai dans l'autre sens...

François :

Vérification des liens morts dans VizieR à mettre en place ?

On pourrait mettre en place un outil de type web-crawler qui vérifie automatiquement (~1 fois par mois) les liens externes et entre catalogues dans VizieR. Les liens externes peuvent changer (d'où l'utilisation du GLU dans certains cas) et des corrections de labels sur un catalogue peuvent entraîner la mort de liens faits depuis d'autres catalogues (ou tables) sur celui-ci.

Remarque : les liens vers SIMBAD ne peuvent pas être analysés via cet outil qui signale seulement que le lien renvoit quelque chose.
Pour rappel : les liens vers SIMBAD se font au moment de la préparation du catalogue grâce à la commande getobj (qui compare la liste des noms donnés en entrée avec ceux de SIMBAD et qui renvoit l'objet correspondant ou l'indication que le nom est mal écrit ou que l'objet n'existe pas dans la base). SIMBAD étant dynamique (avec disparition/modification de certains identificateurs), les liens à un instant t+1 ne fonctionneront peut-être plus...

NB: Gilles doit vérifier avec Anaïs qu'en cas de modification de SIMBAD, les URLs ne doivent pas changer (pour maintenir les liens de VizieR vers SIMBAD).

J/ApJ/770/1 : les magnitudes sont toujours stockées en mmag...

Essai d'un \vizSQL avec des conditions sur les magnitudes qui ne fonctionnait pas. En fait, les magnitudes étant stockées en mmag, il aurait fallu multiplier les valeurs par 1000.
Mais en l'occurrence, l'ajout d'un flag pour préciser si les magnitudes viennent du 2MASS ou de UKIDSS n'est pas nécessaire...

Par contre, petit point de précision : puisque magnitudes stockées en mmag par défaut, le \vizSet avec dbunit=mmag pour laisser passer des magnitudes >32 ne devrait servir à rien.
En regardant l'exemple du J/ApJS/213/19, dans METAcol, on voit que le dbtype est passé à 4. En fait, c'est cela qu'on devrait logiquement mettre dans le vizSet pour autoriser les magnitudes >32 : dbtype=i4 .
Mais le plus souvent une magnitude >32 n'a pas de sens et on veut au contraire autoriser le programme à les tronquer via dbtype=i2t (en mettant le "?" dans le ReadMe pour que les valeurs ne soient pas afficher dans VizieR). Voir CR du 21/01/2014 où il faudrait enlever l'option dbunit=mmag du coup ?

Normalement, François a fait en sorte que le programme se débrouille tout seul sans demander si on veut tronquer ou pas lorsque les magnitudes ont leurs valeurs limites définies entre crochets dans le Readme.

J/ApJ/770/L13 : pour les lignes avec des blends, afficher toutes les lignes de même fréquence observée

Dans ce catalogue, les nombres quantiques étaient en format A (caractère) alors que ce sont des nombres entiers dont les valeurs limites sont intéressantes à avoir...

Par ailleurs, le flag qui indique "blend avec la ligne précédente si elle ne contient pas de flag" n'est pas gênant. A priori, les lignes de la table ne seront pas mélangées via un tri sur une colonne et si on affiche la liste des mêmes fréquences observées, on retrouve les lignes dans le bon ordre avec les différents flags de blend...

J/ApJ/770/16 : S/N n'a pas d'unité

On ne met pas d'unité pour le signal/bruit. Ici "1/Angstroem" est le rapport dans un intervalle de 1 Angstroem.

J/A+A/570/A2 : François a extrait des fichiers ASCII pour chaque spectre afin de tracer les spectres

Avec le fits2a -TOC du fichier FITS contenant les spectres, on s'aperçoit que tous les pectres (1375) sont contenus sur une seule ligne...

Sylvain :

J/AJ/149/5 : la VOTable proposé renvoit un message d'erreur alors qu'elle fonctionne chez Greg ?

En fait, en enregistrant le fichier, on s'aperçoit qu'il manque la fermeture de la balise LINK. En ajoutant seulement, /> à la fin de cette ligne 10, et en rouvrant le fichier dans un navigateur (via Ctrl O ou en remplaçant http par file), le fichier s'ouvre correctement.
Greg doit donc avoir un navigateur plus efficace que le notre qui interprète et ajoute la fin de la balise !

-- EmmanuellePerret - 2015-02-17