Réunion VizieR 05/01/2021

Présents (BBB) : Coralie F., Gilles L., Giacomo M., Pierre O., Emmanuelle P., Patricia V.

Datacube FITS pour la base de données associées

J/ApJ/876/70 : le getimg n'a pas réussi à trouver l'unité des longueurs d'onde -- quelle est la formule pour remplir les lambda min et max du fichier obscoreimage à la main ?

Le fichier FITS fournit est le "full ^12^CO J=2-1 data cube spanning 164.113km/s to -172.935km/s in intervals of 1.056km/s" + "array used the 230GHz receivers" (selon Description du ReadMe).

Le Header FITS indique :

CTYPE3  = 'VRAD    '
CRVAL3  =   1.641132721803E+05
CDELT3  =  -1.056577970338E+03
CRPIX3  =   1.000000000000E+00
CUNIT3  = 'm/s     '

qui sont les valeurs min (CRVAL3) et l'interval (CDELT3) de vitesses du spectre en m/s et

RESTFRQ =   2.305380000000E+11 /Rest Frequency (Hz)

le RESTFREQ, soit la fréquence au repos

On trouve également l'information des intervals min et max, en m/s toujours, en utilisant la commande fits.list file.fits, qui nous donne :

#Position       scale   dim     DATE-OBS        bVRAD   BVRAD   dVRAD   size   FileName Title
308.09359+40.32920               240x 240x 320  2012-07-08T07:08:12.004681     -172935  164113  1056.58 72008   DR15_CO.fits
#dim=240x240x320

Avec bVRAD et BVRAD à -172935 m/s et 164113 m/s et l'interval à 1056.58m/s

On peut donc calculer les lambda min et max à indiquer dans le fichier obscoreimage pour la base de données associées via la formule :

numin=nu0*(1+vmin/c) 
numax=nu0*(1+vmax/c)
avec 
vmin=-173 km/s
vmax=+165 km/s
nu0=RESTFREQ 
c=3.e5 km/s (vitesse de la lumière)

Avec numin et numax en Hz.

N.B. : pour le getimg , il s'agit sans doute d'un problème de reconnaissance de l'unité "m/s", Laurent Michel doit regarder mais ce n'est pas dans ses priorités...

Em : Sauf qu'en fait, si on regarde le compte-rendu de mars 2019, en ajoutant simplement l'unité 'Hz' dans obscoreimage, le programme trouve bien des min et max values automatiquement...

Liens NED

J/ApJ/878/55 : le \vizNED n'a pas l'air de fonctionner. Est-ce que c'est dû à la nouvelle version de NED et est-ce qu'il ne faudrait pas modifier le lien pour pointer vers la nouvelle page systématiquement ?

A priori, l'erreur sur J/ApJ/878/55 était temporaire puisque le lien fonctionne actuellement.

Gilles propose de modifier l'ancienne URL vers la nouvelle (après consultation de l'équipe NED).
Par exemple :
Vielle url : http://ned.ipac.caltech.edu/cgi-bin/nph-objsearch?objname=SPT-CL J0002-5224 &extend=no&out_csys=Equatorial&obj_sort=RA+or+Longitude&zv=z&zv_breaker=10000.0
vs nouvelle url : https://ned.ipac.caltech.edu/byname?objname=SPT-CL J0000-4356 plus lente mais plus complète et sans doute plus pérenne.

-- EmmanuellePerret - 2021-01-05