Réunion JMMC / OCA du 24/03/2011

Etat des lieux

PIVOT comprend une base de données pour stocker les proposals (programmes d'observation et chaque observation) VEGA (CHARA) et une application cliente (Java GUI) qui gère déjà les étapes 1 (création des proposals par les astronomes) et 2 (revue par le PI). Jérome Gerakis est en CDD sur pivot jusqu'à fin mai.

ASPRO 2 est une application Java qui sait déjà dialoguer avec d'autres applications (SearchCal et LITpro pour l'instant) en utilisant le standard SAMP et l'implémentation JSAMP (mark taylor) : ASPRO2 - Interoperability

JSAMP permet de lancer un hub (interne) et de s'y connecter pour échanger sur le bus SAMP des messages identifiés par leur MTYPE (message type).

Voici les messages du STANDARD SAMP:

• LOAD_VO_TABLE("table.load.votable")
• LOAD_FITS_TABLE("table.load.fits")
• LOAD_FITS_IMAGE("image.load.fits")
• LOAD_SPECTRUM("spectrum.load.ssa-generic")
• LOAD_BIBCODE("bibcode.load")
• HIGHLIGHT_ROW("table.highlight.row")
• SELECT_LIST("table.select.rowList")
• POINT_COORDINATES("coord.pointAt.sky")
• GET_ENV_VAR("client.env.get")

Voici les messages spécifiques du JMMC:

• SEARCHCAL_START_QUERY("fr.jmmc.searchcal.start.query")
• LITPRO_START_SETTING("fr.jmmc.litpro.start.setting")

ASPRO 2 supporte le message standard LOAD_VO_TABLE mais de manière spécifique (VOTable SearchCal) : ceci pourrait constituer une piste d'amélioration pour accepter une VOTable qui contient une liste d'étoiles.

Il est donc envisagé d'utiliser l'interopérabilité SAMP pour que PIVOT et ASPRO dialoguent ensemble.
Il faudra donc spécifier les nouveaux types de messages SAMP pour PIVOT avec leur MType et les données utiles et dans quel sens (PIVOT => ASPRO ou ASPRO => PIVOT).

Point technique : il n'est pas possible de lancer une application depuis une autre en utilisant SAMP.
Laurent a exprimé ce besoin au groupe SAMP (IVOA) et le JMMC pourrait développer une solution simple pour couvrir ce besoin = lancer une application capable de traiter tel message SAMP (MType)

Enfin, il est envisageable de couvrir certains besoins PIVOT (calcul des pupilles + plot / Beams / trouver la configuration optimale) en créant des patchs / contributions au code d'ASPRO 2; il faudrait donc founir les sources d'ASPRO 2 (+ JMCS + OITools) à l'équipe de Nice : à réfléchir.

Besoins PIVOT / Phases

Phase 1

Les astronomes créent leur proposal dans l'interface PIVOT (GUI). Ils ont éventuellement besoin d'ASPRO pour déterminer si une source est observable pour une configuration VEGA donnée et à quelle période de l'année.

=> PIVOT appelle ASPRO 2 :

• 1 seule Target avec (au moins) NOM, Identifiant, coordonnées RA / DEC, (magnitudes optionnelles)
• Instrument (VEGA), 1 Configuration (Base)
• Plage de dates (période)

DM: "Est-ce que seulement l'identifiant ne peut pas suffire de sorte qu'une seule source (ASPRO) fournisse les informations complémentaires ?"

LB: "C'est plus simple si PIVOT fournit les coordonnées car cela évite d'intérroger Simbad (latence réseau, problèmes de proxy ...) qui impose alors un traitement compliqué car ces requetes sont asynchrones ! Est ce que PIVOT a au moins les coordonnées ? à approfondir
Quelles sont les informations de(s) target(s) utiles à PIVOT en retour ?"

Question: bloquer certains champs de l'interface (interferometre ...) : à voir

=> Retour : indication si la target est observable OUI/NON avec une durée d'observabilité > seuil (2H) + période d'observabilité : format à définir.

Note: le fichier Aspro2 (asprox) contient beaucoup plus d'information (modele, magnitudes) mais ne semble pas utile dans le contexte PIVOT : PAS d'échange du modèle de l'objet.

Phase 2

Le PI (utilisateur avancé) étudie les proposals pour les programmer les nuits et trouver les configurations optimales d'observation. Il utilise ASPRO pour chercher la configuration optimale pour une liste d'étoile en terme de POPS / BEAMS / PUPILLE.

=> PIVOT appelle ASPRO 2 :

• liste de targets (meme information que le message de Phase 1)
• Instrument (VEGA), 1 Configuration (Base)
• Plage de dates (période)

i.e. utiliser le meme message qu'en Phase 1 mais il faut surement indiquer à Aspro la phase PIVOT pour gérer différemment certaines contraintes et bloquer certains champs de l'interface.

Le PI "joue" / ajuste les PoPs / Beams / Pupille =

• Ajouter la notion de beams à ASPRO 2 :
  • définir les valeurs par défaut des beams / configuration i.e. S1 S2 (Beam2 Beam3) : déjà supporté par ASPRO2 mais valeurs à définir par DM.

DM: "Ok je prépare une table des configurations"

• • ajouter des champs pour forcer les Beams dans Aspro 2: comment ?

DM: "On peut se baser sur les associations par défaut que je vais fournir" LB: "donc pas de configuration manuelle des beams (alors que c'est possible pour les PoPs)"

• • modifier l'algorithme qui cherche le meilleur Pop pour une liste de targets pour qu'il étudie aussi toutes les combinaisons de Beams => meilleur couple (Base / Pop / Beam) => règles / algo à définir

DM: "En fait l’algo sur les POPS ne sera pas réellement modifié par les beams. Par contre si dans cet algo on rajoute la contrainte des pupilles là oui l’optimisation ne sera pas la même."

Cela ressemble à un "switchyard dynamique" (pourrait être utile au VLTI si les opérateurs avaient la liberté de changer quelque chose)

• Ajouter dans les Plots (Pop + Beams) dans les légendes...

Il faut aussi ajouter le calcul du déplacements de pupille : à voir avec Denis. Comment faire ? sous la forme d'un plugin ou alors isoler le code Pop + Beam + Pupille et utiliser des critères pour maximiser l'observabilité (revoir l'algo actuel). DM: "Je peux fournir le code, c’est vraiment simple. Une première étape serait de rajouter en plus de l’observabilité l’information sur la position des pupilles quand celles-ci sont dans la limite acceptable."

A priori, pas besoin de plot spécifique (pupille ...) DM: "Oui correct."

=> Retour PIVOT : meilleure configuration = (Base + Pops + Beam) pour une plage de date (meilleure date ? i.e. avec la contrainte de la nuit ?) DM: "Pour la plage de date. A ce niveau de PIVOT le choix des dates optimales n’est pas encore nécessaire"

Phase 3

Les astronomes finalisent leur proposal (ajout des calibrateurs).

=> PIVOT appelle ASPRO 2 :

• 1 target (meme information que le message de Phase 1)
• Instrument (VEGA), 1 Configuration (Base + Pop + Beam)
• Plage de dates (période)

Aspro2 appelle SearchCal et récupère des calibrateurs ou alors saisie manuelle des calibrateurs.
Quelles sont les informations nécessaires à PIVOT concernant les calibrateurs ? (diametres ?)
Besoin du modèle de l'objet ??
DM: "Le diamètre UDDR suffit avec bien sûr l’identifiant associé !"
LB: "OK, seul le diametre UD en bande R (champ SearchCal UD_R si bien présent dans le retour SearchCal).
Ma question portait sur l'étoile de science: a-t-elle un modèle ? est ce que pivot le connait ? Est ce que l'utilisateur le crée dans ASPRO2 et le fournit à PIVOT ?"

Il faudra vraiment bloquer certains champs de l'interface pour éviter des changements génants (interferometre/ Pop / Beams ...) pour que le fichier StarList reste cohérent.
DM: " Oui cela est nécessaire."

Ajouter une configuration avancée de la configuration spectrale (les modes "AMBER" like ne suffisent pas) => plage de longueur d'onde ... à réfléchir en termes génériques (utile VLTI ?) : faut - il en plus une interface spécifique VEGA pour gérer cela (extension / plugin ?)
DM: "Nous utilisons au fond un nombre limité de configurations. Peut-être pourrions nous nous orienter vers quelque chose comme AMBER après tout...J’en discute avec les collègues."

=> Retour PIVOT : choix de la date + calibrateurs + observation => fichier StarList avec 1 ligne pour target et 1 ligne pour calibrateur (1 seul ?)
DM: "En fait selon choix de l'astronome dans Searchcal en fait." LB: "Combien de calibrateurs min / max ?
attention: dans ASPRO2, l'utilisateur peut saisir ses calibrateurs manuellement et supprimer des calibrateurs venus de SearchCal"

Phase 4 et 5

Autre Phases: Pas besoin de ASPRO ?

DM: "Dans ces phases on utilise en fait la même chose qu’en phase 3 ci-dessus mais avec plusieurs objets. " LB: "A préciser"

Conclusions

LB: " beaucoup de travail / spécifications à préciser.

Il faudrait approfondir les scénarios d'utilisation (use case) et affiner le messages échangés (données, format ...)

Je vous fournirai aussi le code SAMP que nous utilisons la semaine prochaine."

DM: " Je pense que l'on peut définir les priorités suivantes:

1. ouvrir la communication PIVOT-ASPRO: JG/JMC + JMMC
   définition et implémentation des messages dans les différents cas et dans les deux sens
2. ensuite on passe tout de suite à la question de l'ajout réaliste des beams dans ASPRO2 mais cela engendre pas mal de choses:
   • définition d'une table de correspondance: simple à implémenter mais engendrera rapidement des limitations pour VEGA
   • choix par l'utilisateur: ajouts de fonctionnalité dans ASPRO: volume de travail?
3. une fois que cela est fait
   
   • ajout sous les barres d'observabilité d'une barre indiquant pour chaque pupille la période acceptable compte tenu des contraintes
   • modification de l'algo d'optimisation des POPS pour prise en compte des beams (si on les fixe) ou optimisation globale POPS+BEAMS
4. implémentation des modes instrumentaux de VEGA
   • définition d'un nombre réduits de modes
   • complétion des fichiers starlists

Effectivement cela fait pas mal de boulot...et il faut bien réfléchir pour que ces implémentations nouvelles si on les décide se fasse dans l'esprit ASPRO2, c'est à dire multi-interféromètre! "