Introduction

Cette page est dédiée à l'interopérabilité entre les applications PIVOT et ASPRO2.

Liens utiles:

• ASPRO2:
  • page web
  • documentation
  • ASPRO2 - prod
  • ASPRO2 - beta
  • ASPRO2 - dev
• PIVOT:
  • TODO

Description générale de PIVOT

DM a écrit le 23/03/2011:

" Nous avons pour l'instant un client java qui interagit avec une base de données qui nous sert à gérer les différentes phases de préparation des runs VEGA.

On distingue 5 phases:

1. les astronomes déposent des proposals (besoin interactions ASPRO2, VMT essentiellement)
2. le PI gèrent toutes les proposals pour globaliser la demande de temps VEGA (interaction ASPRO2) et définir un nombre réduit de configurations CHARA (TEL+POP+BEAM, 2T, 3T, 4T)
3. les astronomes finalisent leurs proposals sur la base des configs et des nuits disponibles en fournissant le starlist (interaction ASPRO2, SEARCHCAL) et les fichiers de stratégie (PIVOT)
4. le PI d'un run gére à travers PIVOT la planification optimale des nuits du run
5. l'astronome de nuit organise le planning de nuit de manière optimale.

Nous voulons donc pouvoir interopérer PIVOT avec ASPRO2 et SEARCHCAL de la manière suivante:

1. phase 1: envoi d'une target+base à ASPRO2. pas de retour nécessaire
2. phase 2: envoi d'une liste de targets + 1 base à ASPRO2. Retour de la config optimale en terme de POP et BEAM (pour les POPs ASPRO2 est prêt; pour les beams, il faut ajouter dans ASPRO2 le plot des déplacements de pupille. Intérêt pour CHARA en général).
3. phase 3. envoi d'une target+config. Dans ASPRO2 lien avec SEARCHCAL pour calibrateurs puis génération des lignes du starlist par ASPRO2 (ajout des configurations VEGA dans ASPRO2).

Comment avancer:

1. il faudrait donner les bonnes informations à JG et JMC sur les moyens de communication. Comment un programme se connecte à ce vous appelez le "hub? Ainsi qu'un descriptif des champs xml, des UCD si cela existe.
2. je peux décrire dans les jours à venir les ajouts nécessaires sur les pupilles et sur les configs instrumentales afin d'estimer le travail nécessaire. Tout cela existe dans VEGA_PLAN et c'est donc une transcription dans ASPRO2 à faire. Calculs simples pour les pupilles (on doit connaitre tel, pop, beam, positionLar) et pour la config instrumentale c'est des listes de choix.
3. on discute de tout cela. Demain matin fin de matinée si vous voulez? "

Réunions

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! "

Points techniques

JSAMP

Le module JMCS utilise la librairie JSAMP 1.2 (Made by Mark Taylor, working in the Astrophysics Group at Bristol University).

L'archive suivante contient les classes java utilisées pour réaliser les échanges SAMP entre ASPRO2 et SEARCHCAL: jmmc-SAMP-src.zip: JMMC JSAMP code

Quelques explications:

• Barre des menus (inclus le menu Interop):
  • src/fr/jmmc/mcs/gui/MainMenuBar.java
• Classes dédiées à JSAMP:
  • src/fr/jmmc/mcs/interop/SampMessageHandler.java : custom message handler
  • src/fr/jmmc/mcs/interop/SampManager.java : samp client interface (hub, register mtypes ...)
  • src/fr/jmmc/mcs/interop/SampCapability.java : mtype enumeration
  • src/fr/jmmc/mcs/interop/SampCapabilityAction.java : base Samp action (integrated into interop menu) to send Samp messages
• SEARCHCAL (VOTable):
  • src/fr/jmmc/scalib/sclgui/VirtualObservatory.java : see ShareCalibratorsThroughSAMPAction to send calibrators (VOTable)
• ASPRO2:
  • src/fr/jmmc/aspro/gui/action/SampSearchCalQuery.java : appel de SearchCal depuis ASPRO2 (utilise le template ci-dessous)
  • src/fr/jmmc/aspro/gui/action/SearchCal_template.xml : template SearchCal query
  • src/fr/jmmc/aspro/gui/action/BroadcastToModelFittingAction.java : appel de LITpro depuis ASPRO2 (oifits + object model)
  • src/fr/jmmc/aspro/model/searchCal/SearchCalSampMessageHandler.java : traite le retour de SearchCal (VOTable) via XSLT
  • src/fr/jmmc/aspro/model/searchCal/scvot2AsproObservation.xsl : XSLT pour obtenir un format "asprox" de la VOTable

ASPRO2 / SearchCal

Le 24/03/2011 13:47, JMC a écrit :

JMC: " Peux tu me passer un exemple de contenu de votable ou fichier xml que vous échangez entre ASPRO2 et Searchcal ?"

GM: "Dans le sens SearchCal - ASPRO2, c'est exactement le meme format que ce qui est enregistré par SearchCal. C'est une votable searchcal qui du coup s'ouvre avec Aladin en chargement traditionnel ou par SAMP: tu peux selectionner des lignes de la table SearchCal et les envoyer dans Aladin en allant dans le menu Interop.

Tu peux trouver un exemple dans la doc ASPRO2 : SearchCal-hip1234.scvot: SearchCal VOTable for HIP 1234

Dans le sens ASPRO2 vers SearchCal, c'est une votable specifique qui est envoyée :SearchCal_template.xml: SearchCal query template"

JMC: "Avez vous déjà réfléchi à des UCD pour ces échanges ?"

GM: "Les UCD sont ceux de SearchCal, mais tu veux probablement parler des MTypes pour declarer les types de message SAMP ? (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampMTypes)"

ASPRO2 Export(s)

ASPRO2 peut déjà exporter "des informations" aux formats suivants:

• OB VLTI (AMBER / MIDI / PIONIER)
• OB VEGA (StarList)

Une demande d'évolution d'Isabelle Tallon-Bosc a été remontée (ASPRO2 : Bug Report - [#1286892262] / 12/10/2010):

"Serait-il possible de sauvegarder les indications d'observabilité dans un fichier (format à définir) que l'utilisateur pourrait visualiser avec un outil de son choix ?

Les données seraient donc :

HD

date(YY.MM.DD)

UT_transit

UT0

UTfinal

UTmin

UTmax du trou de pointage au zénith (s'il existe)

UT0

UTF_civil twilight ou UTF_astronomical twilight selon la préférence choisie

"

DM a répondu le 19/11/2010:

"effectivement ce besoin est important par rapport aux applications de gestion des observations ou de planification des nuits. C'est vrai que cela devient un peu spécifique à un instrument/réseau mais on peut trouver des choses génériques assez facilement.

Cela passera effectivement par l'export (ou l'interop d'application) des fichiers StarList (ou plus généralement des fichiers OBs) vers un outil de gestion de semestre/runs/nuits via une base de données, qui servira aussi à la gestion des proposals. C'est ambitieux mais l'objectif derrière tout cela est d'aider à apporter des réponses à la critique qui est faite à l'interférométrie d'être une technique d'abord complexe. "

En conclusion, il est apparu nécessaire de faire évoluer les exports d'ASPRO2: LB " pense techniquement qu'il serait judicieux d'utiliser un format XML (VOTable) intermédiaire pour stocker toutes les données calculées par ASPRO2 (absolument tout ce qu'il 'sait') et transformer ensuite ce format pivot en :

• OB Eso pour le VLTI
• OB Vega
• Fichier ASCII d'isabelle (si toujours nécessaire)
• Fichier Excel (format XML) si besoin

Ces modifications techniques permettront d'être plus à l'aise dans les demandes futures de nouveaux exports ou d'évolution des exports actuels ...

Files

Voici les différents fichiers utilisés dans cette page:

• CHARA.xml: ASPRO2 CHARA Configuration
• AsciiFileDescription.doc: Format du fichier StarList (à faire évoluer surement par DM)
• StarList_V01.txt: StarList sample
• SearchCal_template.xml: SearchCal query template
• jmmc-SAMP-src.zip: JMMC JSAMP code