Analyse de la Version du 19 juillet 2011 du Catalogue CDS

En cours

Etude statistique du catalogue pour détecter toute éventuelle modification suite au nettoyage de code SearchCal

• contient 39449 calibrateurs filtrés (38742 JsdcV1) (464 étoiles ont disparues et 1171 nouvelles sont apparues)
• 22h15min pour la recuperation des 21531 VOTables
• version du serveur : developpement
• version fits dispo en ligne : http://jmmc.obs.ujf-grenoble.fr/~betaswmgr/CDS-run-2011-07-19T18-08-35/result/final.fits

Ce qui a changé par rapport à la version antérieure du serveur searchcal:

• un nouvel algorithme de décodage du type spectral plus précis. Il récupère mieux la classe de luminosité et 'sauve' certains types spectraux qui n'étaient auparavant pas compris, donc rejetés. On aura donc d'une part des étoiles classés auparavant "naines" (du fait du non-décodage de la classe de luminosité) qui seront correctement interpétées comme géantes, d'autre part des étoiles dont le type spectral pourra avoir varié de quelques places, ou qui ne seront pas rejetées pour absence de type spectral
• l'algo ci-dessus décode une éventuelle binarité vue dans le spectre, donc une binarité nécessairement très proche (1 à 2 secondes d'arc). On y associe un flag de binarité de type "S".
• le calcul de Teff, Logg et des diamètres uniformes est fait en interpolant les valeurs données dans les tables.

Calculs erronés pour les Teff et Logg de

HIP26207 HIP109556 Ici teff=99.99 (valeur de blanking...) et anciennement (32000 ou 26000)

# Name_1    RAJ2000_1    DEJ2000_1    pmRA_1 pmDEC_1 Bmag_1 Vmag_1 Rmag_1 f_Rmag_1 Imag_1 f_Imag_1 Jmag_1 Hmag_1 Kmag_1 LDD_1 e_LDD_1 UDDB_1 UDDV_1 UDDR_1 UDDI_1 UDDJ_1 UDDH_1 UDDK_1 plx_1 e_plx_1 SpType_1  Teff_SpType_1 logg_SpType_1 Name_2    RAJ2000_2    DEJ2000_2    pmRA_2 pmDEC_2 Bmag_2 Vmag_2 Rmag_2 f_Rmag_2 Imag_2 f_Imag_2 Jmag_2 Hmag_2 Kmag_2 LDD_2 e_LDD_2 UDDB_2 UDDV_2 UDDR_2 UDDI_2 UDDJ_2 UDDH_2 UDDK_2 plx_2 e_plx_2 SpType_2  Teff_SpType_2 logg_SpType_2 Separation
  HIP26207  "05 35 08.277" "+09 56 02.97" -1.29  -1.97   3.355  3.532  3.588  0      3.706  0      3.735  3.769  3.876  0.349 0.024   0.338  0.339  0.341  0.342  0.344  0.345  0.345  3.07  0.76    "O8 IIIe" 26000.0       3.278         HIP26207  "05 35 08.277" "+09 56 02.97" -1.29  -1.97   3.355  3.532  3.588  0      3.706  0      3.735  3.769  3.876  0.349 0.024   0.327  0.328  0.329  0.333  0.341  0.343  0.344  3.07  0.76    "O8 IIIe" 99.99         104.368       0.0       
  HIP109556 "22 11 30.576" "+59 24 52.16" -6.94  -10.98  5.281  5.079  4.77   1      4.62   1      5.053  4.618  4.5    0.423 0.029   0.413  0.414  0.416  0.417  0.419  0.419  0.42   2.06  0.46    O6Iab:... 32000.0       2.978         HIP109556 "22 11 30.576" "+59 24 52.16" -6.94  -10.98  5.281  5.079  4.77   1      4.62   1      5.053  4.618  4.5    0.423 0.029   0.385  0.388  0.393  0.399  0.406  0.408  0.411  2.06  0.46    O6Iab:... 99.99         3.178         0.0   

Detection de la binarite

SearchCal n'ajoute pour l'instant le flag S que si MultFlag est vide. On constate que le filtrage pour le JSDC ne prend pas en compte le nouveau flag S dans MultFlag. Plus généralement, la question se pose de savoir si on doit éliminer les étoiles 'à flag S'. Cela ne se fait pas systématiquempent en effet si l'étoile est déjà marquée comme binaire (flag 'C' par ex) le flag 'S' ne remplace pas le flag existant. Donc trois cas pour ces étoiles spectralement binaires:

• flag 'S' : elle n'est pas éliméinée par le filtrage pour l'instant (à corriger évidemment!)
• autre flag et présente dans SBC9 : éliminée
• autre flag et présente dans WDS: éliminée que si la binaire est séparée de moins de 2 arcsec. Et c'est là qu'il y a problème.