Stage de Roman Bonnet - TPS 1ere année - [ 5 semaines 17/06/24 au 19/07/24]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter Sébastien

Sujet

• Titre : Analyse des Measurements SIMBAD pour les missions spatiales.
• Objectifs : La base de données SIMBAD, maintenue au CDS (Centre de Données astronomiques de Strasbourg) depuis plus de 40 ans, est une
  référence mondiale qui contient des mesures et informations bibliométriques pour près de 18 millions d'objets astronomiques. Parmi
  les mesures associées figurent des liens vers les spectres du satellite IUE, mission spatiale d'observation dans l'UV, qui ont été
  ajoutés aux objets de SIMBAD en 1996 (les données IUE sont accessibles sur plusieurs archives, en Espagne et Italie), et sont
  toujours utiles presque 3 décennies plus tard.Le but du stage est de faire un état des lieux du contenu SIMBAD concernant les
  mesures IUE, et préparer la mise à jour du contenu en actualisant les liens vers les données archivées pour le plus grand nombre
  d'objets possible.Actuellement, seulement 7457 objets ont des données IUE associées dans SIMBAD, et ce nombre pourrait
  probablement être augmenté de 15% en 2024, compte tenu de l'évolution de SIMBAD.

Stage

Semaine 1

Pour commencer, il faut récupérer les données IUE de la table INES (IUE Newly Extracted Spectra) appartenant à Vizier. Il est possible de faire cela par le service TAP de la plateforme avec la commande

ADQL command

SELECT * FROM "VI/110/inescat" WHERE IUEClass > 7 AND IUEClass < 91

La restriction sur l'attribut IUEClass permet de ne pas sélectionner les études sur le système solaire (Classes 1 à 7), ou toute autre opération sur la calibration du satellite (Classes 98 et 99). Cette table est au format VOTable et contient 97297 lignes. Elle sera par la suite désigner par la table "vizier". Désormais, il nous faut extraire de cette table les éléments n'appartenant pas aux données Simbad. Pour se faire, il faut utiliser le service TAP de Simbad dans lequel nous aurons pris le soin de charger la table "vizier". La commande suivante permet d'éxécuter cette tâche :

ADQL command

SELECT TAP_UPLOAD.vizier.Object FROM TAP_UPLOAD.vizier LEFT JOIN ident ON TAP_UPLOAD.vizier.Object = ident.id WHERE ident.id IS NULL GROUP BY TAP_UPLOAD.vizier.Object

L'attribut Object de la table "vizier" contient les noms normalisés (id) de chaque object. Nous prendrons le soin d'appeler cette nouvelle table "viezer_G1_u". Par ailleurs, nous pouvons également télécharger la table "vizer_G1_k" :

ADQL command

SELECT TAP_UPLOAD.vizier.Object FROM TAP_UPLOAD.vizier LEFT JOIN ident ON TAP_UPLOAD.vizier.Object = ident.id WHERE ident.id IS NOT NULL GROUP BY TAP_UPLOAD.vizier.Object

qui repertorie les ids des objets appartenant à Simbad. Cette table nous servira plus tard pour la vérification.

Travail de tri

On commence donc à exploiter "viezer_G1_u" qui contient 960 lignes. On remarque que beaucoup de lignes commencent par "MC" (Magellanic Clouds). Prenons un exemple : "MC BI 8" n'est pas reconnu par Simbad tandis que "BI 8" l'est et c'est le cas pour un grand nombre d'objets. Une première approche consiste donc à modifier cette colonne Object en une identique mais sans les "MC" au début des noms Object. Il faut cependant faire attention aux entités Object qui contiennent le string "MC" sans pour autant être au début du nom. Il est préférable d'appliquer la fonction trim() à l'attribut Object avant de continuer afin de supprimer les espaces en début de string. Ceci étant dit, la modification se fait aisément sur topcat avec la commande suivante :

topcat command

startsWith(Object, "MC") ? replaceFirst(Object, "MC", "") : Object

On sauvegarde la table obtenue sous le nom : "vizier_G1_u_modified". On réalise ensuite un nouveau X-match entre cette nouvelle table et la table ident de Simbad.

ADQL command

SELECT TAP_UPLOAD.vizier_G1_u_modified.Object FROM TAP_UPLOAD.vizier_G1_u_modified LEFT JOIN ident ON TAP_UPLOAD.vizier_G1_u_modified.Object = ident.id WHERE ident.id IS NULL GROUP BY TAP_UPLOAD.vizier_G1_u_modified.Object

On appelera cette table "vizier_G2_u". De la même manière que pour le premier X-match, nous pouvons également télécharger _"vizier_G2_k" en remplaçant "WHERE ident.id IS NULL" par "WHERE ident.id IS NOT NULL". On obtient alors 2 tables ayant respectivement 200 et 760 lignes.

Exploitons désormais "vizier_G2_u". On peut identifier 15 Object étant de la forme _"HD XXXX x" où X est un chiffre et x un caractère pouvant être A, B, C, D ou J. Ce dernier caractère précise que l'_Object" observé est en réalité un Object avoisinant "HD XXXX", Object que Simbad reconnaît. Le travail peut donc consister à supprimer ces dernires caractères avec topcat et la commande :

topcat command

((endsWith(Object, " A") OR endsWith(Object, " B") OR endsWith(Object, " C") OR endsWith(Object, " D") OR endsWith(Object, " J")) & startsWith(Object, "HD")) ? substring(Object, 0, length(Object) - 2) : Object

La table obtenue est sauvegardée sous le nom "vizier_G2_u_modified". On peut à nouveau réaliser un X-match pour obtenir "vizier_G3_k" et vizier_G3_u". Tous les Object précédemment modifiés sont désormais reconnus. Il ne reste plus que 185 lignes dans "vizier_G3_u". On peut également noté que certains éléments commencent par "ZZ" ou "IUE" et correspondent à des Object dans le système solaire ou à des calibrations, et ne sont donc pas à prendre en compte. Aucune nouvelle règle n'a encore été établie pour améliorer le tri.

Vérification des objets reconnus par Simbad

Le travail consiste désormais à prendre les Object de "vizier_Gx_k" et d'en récupérer les données enregistrées dans Simbad & dans Vizier, plus particulièrerement les RA (Right Ascension) et DE (Declination) et de les comparer pour s'assurer qu'il s'agisse bien du même Object. On réalise en premier lieu un X-match entre les tables "vizier_all" et "vizier_G1_k" via topcat sur les noms Object. On récupère alors toutes les données dans une tables que l'on nomme "vizier_G1_k_data". Puis on effectue une double jointure en TAP sur Simbad pour récupérer les données de Simbad ET de vizier (pour faciliter la lecture, on remplace "vizier_G1_k_data" par "vizier".

ADQL command

SELECT basic.OID, TAP_UPLOAD.vizier.Object, ra, dec, TAP_UPLOAD.vizier.RAJ2000, TAP_UPLOAD.vizier.DEJ2000 FROM basic JOIN ident ON oidref = oid JOIN TAP_UPLOAD.vizier ON TAP_UPLOAD.vizier.Object = ident.id

On appelle la table obtenue "vizierXsimbad_G1_coord". On peut alors l'ouvrir dans topcat et réalisé un histogramme grâce à la fonction skyDistanceDegrees(). Il est alors possible de créer un groupe d'_Object_ éloigné de plus d'une certaine distance minimale qu'il reste à déterminer et de les traiter. Par ailleurs, si un trop grand nombre d'_Object_ dépasse cette distance minimale, la conclusion sera que l'opération de tri / modification de noms n'est pas adéquate.

Semaine 2

Semaine 3

Semaine 4

Semaine 5

-- SebastienDerriere - 2024-06-20