Réunion VizieR 10/02/2015

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

Patricia :

II/309 : table ajoutée par B. Skiff dans ce catalogue

Table ajoutée dans le FTP mais il faudrait les fusionner dans VizieR car les coo de B. Skiff sont bien meilleures que celles d'origine (à mettre en positions secondaires). De manière générale, le regroupement de tables permet d'avoir toutes les informations concernant un objet de manière beaucoup plus efficace que si de simples liens sont faits entre les tables.

AKARI : suite (et fin?)

Patricia a préparé 3 catalogues qui manquaient parmi la liste envoyée (un ApJ de 2014 et 2 PASJ de 2013 mais dont les tables ont été mises en ligne sur le site AKARI en 2014). Elle recharge l'ensemble des catalogues (avec les Mission Name et \cUsualName ajoutés). Ensuite, la liste des références catalogues sera envoyée à Pierre pour qu'il puisse répondre aux auteurs.

Pierre :

Lenteurs VizieR : utilisation d'un web-crawler

Suite à la remarque de Cécile concernant les lenteurs de VizieR, Pierre a utilisé le logiciel gratuit Integrity (http://peacockmedia.co.uk/integrity/) pour MAC qui permet de suivre les URLs à partir de pages VizieR pour voir le temps de réponse de ces pages.
A partir de l'URL J/ApJ/ en "expand search" et de quelques règles pour éviter de suivre des liens externes à VizieR, il obtient un résultat de 1% des temps de réponse >3 secondes et ~ 1 pour mille pour les réponses > 10 secondes.
De plus, généralement, en faisant un re-check des liens qui ont été bloqués en time-out, l'URL fonctionne.
A voir si ce genre d'outil peut servir pour vérifier les ralentissements (voire liens morts) et corréler ces ralentissements avec les opérations simultannées sur VizieR (chargement d'un gros catalogue ; augmentation anormale des requêtes...) ?

Gilles s'occupe déjà de ce problème depuis ~1 an avec François mais pour l'instant les causes ne sont pas bien définies. Il y a déjà eu quelques modifications (limitation du pool de requêtes, time-out au bout de 30 secondes de non utilisation, etc.)

Anecdote rigolote : l'ESA interroge quotidiennement les ~16000 ref. de VizieR via TAP...

Retour AAS

A voir avec Emmanuelle pour regrouper les problèmes soulevés en 4 points et par odre de priorité.

François remarque que ce que nous faisons pour VizieR est l'inverse de ce que recherche l'éditeur : fragmentation des tables, etc.

Emmanuelle :

J/ApJS/215/26 : Le J^{pi}^ level ?

Dans la version HTML, les exposants "e" sont des flags mais pas dans la version MRT. A quoi correspondent-ils ?
En fait, il s'agit sans doute des parités "o" pour odd et "e" pour even et c'est bien dans la version HTML que le flag n'a pas lieu d'apparaître...
Par ailleurs, concernant les f_, il ne s'agit pas de CODE_MISC mais d'ID pour les mixing coefficients correspondants. On peut donc remplacer les labels.

N.B. : les exposants ^N^ et indices _N_ sont stockés tels quels dans la base mais la commande \vizSoft permet de les convertir à l'affichage pour qu'ils soient propres en HTML.

J/ApJS/215/25 : bonne molécules ?

Les molécules de la tables indiquées en "HCOO^1^3^C^H_3_" devraient être HCOO^13^CH_3_ comme dans l'abstract ?
=> oui !
La position de Orion-KL est récupérée de SIMBAD dans la section Object mais les auteurs en donnent une autre. Quelle position garder ?
=> Celle des auteurs !

J/ApJS/215/24 : 4 spectres en FITS ?

Le fits2a -toc donne :

cats@cdsarc(502) fits2a -toc fits/*
#--- fits/spEigenCVstar-53724.fits
#ext xtension bpx (dim)              x2880 extname
#000     main -32 (3905x3)             18b [0/3904(1)] [0/2(1)]

#--- fits/spEigenGal-53724.fits
#ext xtension bpx (dim)              x2880 extname
#000     main -32 (7012x4)             41b [0/7011(1)] [0/3(1)]

#--- fits/spEigenQSO.fits
#ext xtension bpx (dim)              x2880 extname
#000     main -32 (12482)              19b [0/12481(1)]

#--- fits/spEigenStar54474.fits
#ext xtension bpx (dim)              x2880 extname
#000     main -32 (3891x42)           230b [0/3890(1)] [0/41(1)]

"bpx" = byte per pixel, c'est le titre de la valeur -32.
Le premier fichier, par exemple est donc un tableau de 3905x3.
En fait il s'agit des 48 templates des figures 1 et 2 du papier mais les Header ne donnent pas grand chose... On laisse simplement en accès dans le FTP.

Dans les tables 4 et 5, on a "Proper motion along galactic latitude" pour les 2 valeurs de mouvement propre. Le {mu}lcos(b) est le mouvement propre le long de la longitude (= pmGLON). On a donc d'abord pmGLAT puis pmGLON...

François :

J/ApJ/769/108 : Graphe avec erreur bizarre ?

En fait, le problème vient d'un filtre qui n'a pas toujours de données selon l'objet. Lorsqu'il n'y a rien, un message en rouge apparaît furtivement pour indiquer "no data found". Mais en l'occurrence, il ne s'agit pas vraiment d'une erreur...

Par ailleurs, il semble y avoir un bug : lorsqu'on décoche un dataset pour un filtre. Si on le recoche, les erreurs ne s'affichent plus.

Enfin, l'ergonomie pour le widget dès qu'il y a un ensemble de filtres n'est vraiment pas pratique !!

J/ApJ/770/7 : Pourquoi un AddCount alors que la colonne N indique déjà le nombre de membres par famille ?

N'a pas vraiment lieu d'être; effectivement, à part pour vérifier qu'on retrouve bien le même nombre... On peut faire directement un \vizMore sur la colonne N.

Gilles :

Modification pour afficher les colonnes de positions recalculées

Un petit problème d'affichage : lorsqu'il n'y a pas de position recalculées dans un catalogue (pas de colonne _RAJ2000), lorsqu'on clique sur Sexagesimal ou Decimal, rien ne change.
Gilles a modifié le programme pour qu'une colonne recalculée soit automatiquement affichée si elle n'y était pas afin de voir les données calculées.

Néanmoins en testant avec J/ApJ/761/162, si on décoche la colonne "J2000", rien ne se passe en cliquant sur Decimal ou Sexagesimal alors qu'avec cette correction, il devrait y avoir quelque chose.

-- EmmanuellePerret - 2015-02-10