Model fitting & Image reconstruction

The aim of the "Model fitting & Image reconstruction” (MFIR) working group is to provide software interferometric data processing.

Sprints Roadmap

• Sprint1
• SprintEcoleVLTI

Base de données de test

Réunions

4 Octobre 2022 Point de rentrée

OImaging

• Bilan: avec le travail sur 1 ans de Martin, d'Antoine, de Laurent et de Guillaume OImaging a atteint une certaine maturité et est utilisable simple sans trop de bugs
• Bilan: communication à Exceter, EWASS, SPIE et bientot à l'ecole ESO au Chili
• A mon sens reste à voir l'utilisation et les retours utilisateurs pour aller plus en avant dans l'ajout de fonctionnalitées
• En attendant on peut quand meme faire:
  • Doc: meilleurs tutoriels (je veux bien un retour sur la video que j'ai faite) ? un demo settings avec des données (le beauty contest?) comme dans LITpro
  • Bug: repasser sur la liste des bugs dans trac et github (ferreol puis dans un deuxieme temps avec Guilllaume/Laurent/ou Antoine)
  • Reflechir à l'effort que demanderait l'ajout de softs:
    • ORGANIC: voir avec Jacques à propos de la conversion au format Image-OI et s'il a besoin d'aide (Ferreol)
    • IRBIS: faire un test d'installation sur une machine virtuelle (docker?) et évaluer l'effort pour faire un wrapper (Guillaume?)
    • SQUEEZE: re-prendre contact avec Fabien (Ferréol)

Model Fitting (LITpro et Calliper)

• Ajout Genfit dans la doc (ecriture du tex par Hervé)
• Paramètres par défaut: faut il faire quelques tests ou il existe déjà des paramètres par défaut?
• Mode asynchrone: développements prévus novembre-décembre
• doc de calliper initiée dans CodiMD https://codimd.math.cnrs.fr/qO3fu3g-Qm-6XtwXTsaaZQ?view#
• Besoin du collection de tests (voir en particulier) les mails des 9 et 10/02/2022
  • il existe une collection d'OIFITS de callibrateurs non callibré de MATISSE
  • voir https://codimd.math.cnrs.fr/qO3fu3g-Qm-6XtwXTsaaZQ?view#
  • implémentation d'un fit à deux paramêtre dans calliper pour fitter les callibrateurs?
• Définition de modèles
  • Michel et Isa ont écrit une partie du document tex avec les formules
  • il faut encore réfléchir à la partie implementation pratique. En vrac
    • Quelle arborescence du depot
    • doit on faire des test automatiques pour comparer les implémentations?
    • besoin de formaliser un language de description des modèles et des opérations dessus
    • doit on proposer une implémentation image en plus de Fourier?
    • lien avec AMHRA?
    • je propose de raffiner un peu le calendrier sur ce point avec Michel & Isa - ? pas sûre de bien comprendre ce que cela veut dire (Isa)
  • Statistiques de cette année des lancement OImaging version publique
    

    

12 Avril 2022 Review OImaging

Jacques, Miguel et Ferréol Compte Rendu

18 Janvier 2022

Visio : Gilles, Jean-Philippe, Michel, Isabelle, Guillaume, Hervé, Antoine, Ferréol

Bilan

• année d'activité intense autour d'OImaging (Martin + Antoine)
• Modele de développement qui semble convenir à tous via github
  • issues visibles par tous dans le board ,
  • on peut lier issue et PR
  • artifacts permettant de récupérer facilement le jar courant,
  • permet aux CDD/stagiaire d'avoir une vitrine sur leur travail,

OImaging

• OImaging dans une version présentable: release dans la semaine
• PR touchant l'infrastructure à valider par Laurent

une fois la release faite :

• test par les membre du groupe
• test par des utilisateur bien choisi (M. Montarges, J. Kluska & A. Soulain)
• test et validation par les concepteurs de soft: Eric Gilles & John

Tests:

• structurer la reponse de beta testeur : ecrire des questions ou une grille d'évaluation / leur donner un modele
• retour OIfitsExplorer à anticiper
• budgeter du temps pour répondre aux utilisateurs
• faut il faire des test cote à cote?

Futurs développements

• doc à continuer (en particulier doc général)
• diagramme des classes principales
• features:
  • suivi du Chi2
  • calcul du beam et de l'echantillonnage
  • pas mal de cosmétique
  • notion de session et d'arborescence entre runs/hdu
  • polychromatisme
    • selfcal avec Florentin
    • simplifier SPARCO
    • affichage polychromatisme avec CARTAvis
  • grille / tilling a continuer
  • run en parallele

Caliper

• remettre en place la partie serveur (Guillaume)
• mode batch via script python (qq heures de travail Guillaume)
• pb de timeouts à régler
• Guillaume va essayer de réactiver: en attente de retour collègues MFIR
• fournirait un premier moyen de test de l'algo génétique

LITpro

Algo génétique

• code génétique la dernière fonctionalité à valider
• la doc est incluse dans le code
• Ferréol: nécessité de doc sur les paramètres de l'algo pour l'utilisateur
• Hervé: nécessité d'introduire algo génétique fournir à Guillaume qui intégrera ça dans la doc (sources latex disponibles)
• Refaire le TP (practice) de l'école VLTI comme validation
• Hervé: activation calcul sur machine utilisateur. Guillaume: c'est possible. regarder ensemble avec Hervé
• Michel Tallon: explication mode asynchrone à Guillaume
• nécessité temps d'estimation restante
• Possible implication d'Antoine sur le sujet.

Modèles

• Papier
• Ferréol: mise à disposition via github (un répertoire par modèle)
• validation autres implémentations en langage
• Mise à disposition du code: Michel/Isabelle: d'accord sur le principe mais plutôt seconde partie de l'année

sortie OI-Image

• Michel: quid de la sortie des paramètres de fit en format oifits étendu: Ferréol pas urgent dans l'immédiat.
• (rappel: GitHub - JMMC-OpenDev/OI-Imaging-JRA: Design and specification of an interface to image reconstruction and model fitting from optical interferometric data)
• Michel: c'est codé: mise à disposition, un projet pour Antoine

OifitsExplorer

• Isabelle: comment allons-nous fonctionner ?
• JPB/Ferréol: nouveau fonctionnement
  • JPB centralise avec les
  • première phase définir des specs avec des priorités (bilan tickets)
• Guillaume: réintégrer les fonctionalités OiFitsExplorer dans LITPro (plots)

3 Septembre 2021 OImaging à Grenoble

Cette réunion a eu lieu à la fin du stage de Martin et à l'occasion de l'arrivée d'Antoine K. pour un CCD de 6 mois

Participants : F. Soulez, G. Mella, L. Bourgès, I. Tallon-Bosc, J.P. Berger, M. Pratoussy, A. Kaszcszyc, H. Beust (visio), G. Duvert (visio)

Ordre du jour

• Tour de table / présentation
• Démo Oimaging (voir https://www.youtube.com/watch?v=eYsi8HYaspI ) et présentation des développements réalisés pendant le stage de Martin
• Discussions stratégies pour la suite avec Antoine
• Débrief du stage de Martin
• Outils et organisation du projet

Développements réalisés par Martin

• regle interactive pour le mesure des distances et des angles sur l'image reconstruite (permet d'initialiser le model fitting)
• table des résultats en bas avec colonnes variables/ triables...
• affichage (tilling) de différents résultats
• affichage de cubes d'images (à poursuivre) : animation ou sliders

Plan d'action

• mois de septembre
  • Antoine poursuit le travail de Martin sur la table de résultat et l'affichage multiple et se familiarise avec le code
  • revue et tri des tickets (FS + GM & LB)
  • tous le monde: test Oimaging et fait remonter les bugs Listes des bugs/features d'OImaging
• Réunion le vendredi 1/10 à 11h pour faire le points décider de faire une nouvelle release avec annonce sur jmmc-all
• Demande à qqs chercheurs (J. Kluska, M. Montarges, A. Soulan, SUV,...) de tester OImaging et de faire remonter les bug et surtout les features manquantes et leur prioritées
• essais en présentiels pour evaluer l'ergonomie
• courant octobre définir des jalons de développement d'après les priorités remontées.
• même chose sur OIfitsexplorer

Feedback du stage de Martin

• 1ere plongée dans un code existant (effort demandé de comprehension fort en début de stage)

• difficile de voir les features déjà existantes (très compliqué d'éviter les duplications & les conflits)

  • -> besoin d'un diagramme (manque de documentation de design) doc UML, cas d'utilisation)... Difficulté à maintenir la doc à jours.
  • peu de docs de design

• difficile de comprendre le contexte scientifique sous jascent pour comprendre les besoin

  • -> vers des doc d'explication de l'interférométrie pour les nouveaux arrivant?

• difficile parfois de comprend les besoins (ex colonnes de la table)

  • mieux specifier les besoins

• Pas vraiment eu le temps d'explorer le logger

• swing -> javaFX?

• regles de codage compatible avec enseignement
• satisfaction utilisation de github (premières PR)
• point réguliers rapides positifs mais parfois pas suffisant
• utilité de point focalisé d'1H
• Ok pour mettre en ligne sur jmmc.fr/doc le rapport de stage

Outils et organisation

• Outils

  • track : bug report et demande utilisateur

  • board github : avancement projet

  • twiki journal de bord

• Réunions

  • standup meeting 1(pas dépasser les 15mn) à 14h?

  • reunion + poussée avec laurent (1h)

  • qq réunion de groupe (1h par mois?)

• Git
  • eviter de travailler sur plusieurs branches fonctionnelles à plusieurs en meme temps
  • faire plus de PullRequest remanier au minimum
  • eviter les pullrequests qui couvrent plusieurs fonctionnalités -> GitFlow ?
  • difficulté du rebase
  • difficulté de modules séparés:
  • comment grouper une PR sur plusieurs modules

• documenter l'utilisation des loggers java et bonnes pratiques

Janv. 2021 Polychromatic MFIR

Participants : F. Soulez, K. Perraut, M. Tallon, E. Thiébaut, G. Mella, L. Bourgès, P. Cruzalebes, J. Kluska, I. Tallon-Bosc, P. Kervella, T. Paumard, F. Millour, L. Mugnier

Etat des lieux

Plusieurs polychromatismes (JK)

1. Raie Vs continuum (si beaucoup de canaux dans la raie: carte de vitesse + carte largeur de raie + carte intensité de raie)

2. Cube dont les rapports de flux entre pixels varient avec la longueur d'onde (e.g. carte de température)

3. Observation multi-bande ou la morphologie varie radicalement

Softs existants

• LITpro permet d'avoir des modèles "Black Bodies"
• OImaging / SPARCO : ( modele avec un spectre + image avec un spectre différent)

Leçons de POLCA

• Reconstruction d'un cube (PAINTER / MiRA3D) complexe étant donnée la couverture (u,v) du VLTI,
• Reconstruction semi-paramétrique (à la SPARCO) semble plus pragmatique

A l'époque de POLCA nous avions rencontré deux problèmes que nous n'avions pas réglés:

• Ambiguïtés sur les définitions des visibilités/phase différentielle (différence avec une longueur d'onde de référence, avec la moyenne sur le continuum, avec le canal spectral d'avant)
• la SED n'était en général pas accessible empêchant l'ajout d'a priori trans-spectraux physiques

Ces deux points semblent moins problématiques maintenant (la SED est dans la norme OIFITS2) mais il reste a coder l'attache aux données correspondant au modèle différentiel de chaque instrument (au moins pour MATISSE & GRAVITY )

Besoins utilisateurs

Les cas scientifiques sont principalement les étoiles évoluées et les disques (en très schématique). Ces cas astrophysiques ont besoin des deux premiers types d'imagerie (continu Vs raie & cartes) définis plus haut.

Actuellement les images sont reconstruites indépendamment par lambda (avec self-cal/MiRA pour Florentin) . SQUEEZE propose une régularisation trans-spectrale de type Tikhonov.

Actions

Comme plusieurs actions du JMMC, le groupe MFIR pâtit d'un manque de communication avec les observateurs. Il est indispensable d'améliorer/créer les liens avec les observateurs pour aligner les possibilités des outils MFIR avec les besoins des utilisateurs des instruments.

Un bon modèle de développement des fonctionnalités serait de co-développer les fonctionnalités au sein des projets d'observation: les observateurs définissent / prototypent le modèle de leur objet avec l'aide du groupe (via SUV?) puis MFIR se charge de l'intégrer dans LITpro et de le rendre disponible à la communauté.

On peut donc identifier 2 axes:

• A moyen/long terme: créer des liens avec les observateurs c'est à dire participer au montage de projets type ANR (co-encadrer des thèses) et aux demandes de temps. Il faut plus spécifiquement renforcer la communication avec les consortia. D'après KP les observateurs des consortia méconnaissent souvent les outils MFIR alors qu'une collaboration avec MFIR pourrait être gagnant/gagnant. (en profiter pour inciter les consortia a bien suivre la norme OIFITS2 ).
• A court terme, la priorité est la mise en place des "user model" dans LITpro. Cela permettrait certainement d'amorcer la pompe avec les utilisateurs.

L'ESO réfléchit de son côté à des outils d'imagerie (quick look), il est important de se synchroniser avec l'ESO et les autres VLTI-Expertise center (EC). JK propose de faire une réunion avec les autres VLTI-Expertise center sur l'imagerie. Cela rejoint une des actions listées en conclusion du meeting EC/ESO des 19 et 20 janvier : "Work towards defining a data format including OIFITS and reconstructed images", action à entreprendre entre les EC et l'ESO. La façon avec laquelle elle peut être initiée sera discutée dans la première des réunions mensuelles entre EC et ESO (organisation par Antoine Mérand, en cours).

Oct. 2020

Participants : Guillaume, Laurent B, Eric, Gilles, Hervé, Isabelle, Michel, Ferréol

Peu d'activités en 2020. D'ici la fin de l'année avancer sur les points suivants:

OImaging

• Revue de tous les tickets et amélioration de l'ergonomie (Laurent B et Ferréol)
• Profitons du Beauty Contest pour faire utiliser Oimaging par un "innocent" (Alexis Matter?) et avoir des retours sur l'interface et la doc.
• Génération d'une image de départ?

LITPro

• mode asynchrone (Guillaume et ?)
• interface et doc algo génétique (Hervé & Guillaume)
• Ecriture du modèle dans l'OIFITS de sortie à la OImaging (Michel et Ferréol)

Une dernière idée serait de documenter/debugger le mode local de LITpro et OImaging pour le mettre à disposition

Nov. 2019

Participants : Guillaume, Hervé, Isabelle, Michel, Ferréol

Discussions sur le développement de LITpro et les tâches nécessaires pour proposer l'optimisation génétique dans la version distribuée sur le site.

Dans une première phase, on va faire juste ce qui est indispensable pour proposer le fit génétique:

• mode asynchrone du serveur interrogé de temps à autre par le GUI (Guillaume)
• sortie de LITpro en OIFITS avec le modèle dans une table supplémentaire (Michel, Isa & Ferréol). Pour le moment, autant de fichiers d'entrée, autant de fichiers de sortie.
• ajouter les paramètres du fitter avec les valeurs par défaut qui vont bien dans le GUI (Hervé & Guillaume)
• vérifier que toutes les infos nécessaires sont présentes dans le GUI et que les plots vont bien (Hervé & Guillaume)
• tests (tous)
• régler les tickets qui pourraient être résolus facilement cf http://trac.jmmc.fr/jmmc-sw/report/34 (tous)

Guillaume est prêt à y passer du temps début 2020 en fonction des dispos de Michel & Isa

A plus long terme nous avons aussi pointé plusieurs problèmes à régler / améliorations à faire:

• Vérifier la sécurité (exécution de code dans les user model) -> exécution dans des containers à plus long terme,
• est-ce nécessaire de faire voyager un OIFITS complet à chaque ping du GUI ? Est ce que les OIFITS avec les données ne vont pas devenir trop gros ?
• suivi plus interactif en gardant les résultats en mémoire sur le serveur qui peuvent être interrogés au fur et à mesure par le GUI,
• que faire lorsqu'il y a plusieurs fichiers d'entrée (comment écrire la sortie ?)
• comment gérer les données flagguées bad data par LITpro
• homogénéiser les plots.
• OIFITS2

Une partie des ces problemes (flag, fusion de fichiers, sélection) sont communs à tous les softs de traitement des OIFITS. Il sera plus logique de laisser OItools s'en charger avec une interface simplifiant les interactions avec l'utilisateur.

Juillet. 2019

Participants : Guillaume, Laurent B, Gilles, Gregory Savignol, Ferréol

Gregory est IE nouvellement recruté à l'OSUL. Il est chef de projet des base de donnée et doit travailler en appuis des SNO de l'OSUL (MOIO, SPHERE-DC et PsuP). Apres un premier contact avec l'équipe technique, il a participé à cette réunion pour lui presenter MFIR et voir quels implication il pourrait y avoir.

Retour CS: discussions et priorité (a peu pres dans l'ordre de priorité)

• LITpro
  • Ajouter les champ qui vont bien pour le fit génétique
  • code publique et ligne de commange (GD demande si un notebook pourrais faire une GUI minimale pour la ligne de commande)
  • retour format OIFITS comme OIMAGING pour faciliter l'execution asynchrone
  • page web des model utilisateurs
• Base de donnée test
  • recommandation sur un groupe de travail (leger) a discuter lors du passage de ferreol a Grenoble en septembre
• OImaging
  • OItools alignement V2/T3
  • SPARCO dans OImaging (possible en septembre)
  • Doc (cookbook sanchez sur overleaf?), tuto et image de depart
  • image de départ

Jan. 2019

Participants : André, Guillaume, Laurent B, Isabelle, Michel, Gilles, Eric, Hervé, Ferréol, personne de l'OSUG-DC dont j'ai oublié le nom.

bilan 2018 & points à mentionner dans le rapport d'activité

• OItools / OIFITSexplorer ajout de fonctionnalités
• développement OImaging
• MiRA dans OImaging
• Algo génétique (genfit) presque dans LITPro
  • A tester sur la version alha : http://apps.jmmc.fr/~mellag/LITpro/ (JNLP Webstart + lien jar dans la page)

objectifs MFIR pour 2019 (trop ambitieux pour une seule année et non triés):

• proposer dès que possible genfit dans LITPro
• déléguer tous les filtrages (en particulier alignement des V2 et T3) des OIfits à OItools / OIFITSexplorer mais en garder une partie (en longueur d’onde) accessible aussi dans les softs. L’idée de faire un format de donnée intermédiaire (Gilles) ne contenant que les infos utiles ne fait l’unanimité (en particulier Eric).
• Génération d’images de départ: il est nécessaire de proposer un outil pour fabriquer une image de départ pour OImaging. Il pourrait être utilisée par ASPRO. Il reste encore à réfléchir à la forme (GUI) et au fond (protocole + algèbre pour composer des transformations).
• PAINTER: André mentionne que Martin Vannier a tenté d’utiliser PAINTER sur des données MATISSE. André indique que les points les plus bloquants sont: (i) la non compatibilité avec Julia v1.0 et (ii) l’alignement V2 / T3. Tout le monde est unanime sur l’intérêt pour MFIR à passer du temps sur PAINTER pour avoir un algo polychromatique. De plus, l’investissement dans Julia vaut le coup car il est probable que les nouveaux algos soient codés dans ce langage (Eric a déjà une version de MiRA en Julia). Dans un premier temps en ligne de commande. Les taches a faire sont:
  • • passage Julia v1.0 (André propose de s’en occuper)
    • écriture (lecture?) OIfits2 en Julia (Eric)
    • réfléchir à une version polychromatique d'OImaging (tous)
• LITPro ligne de commande et sur Github Michel veut le faire après avoir fini les user-models. Repoussé à après juin car Michel est occupé par THEMIS.
• barres d’erreur LITPro une des critiques des utilisateurs concernent les barres d’erreurs. Michel se demande dans quelle mesure les barres d’erreurs sont fausses. Un MCMC permettrait de caractériser les barres d’erreur. On peut peut être proposer à l’utilisateur un MCMC qui serait utilisé pour calculer des barres d’erreur une fois qu’il est satisfait par la solution de LITPro, en le prévenant que c’est très long

publications citant LITpro, cas scientifiques

• cf la liste http://apps.jmmc.fr/exist/apps/docmgr/jmmc.html#LITpro :
  • peut-être contacter des collègues qui auraient des données pour tester sur des cas plus récents que les jeux de tests fournis avec le code LITpro.

infrastructure

• passage de LITpro en asynchrone: Hervé peut interrompre et reprendre les calculs avec genfit car la structure de données est sauvée à chaque itération. Reste à intégrer ça dans la partie client/serveur
• prédire les ressources utilisées (taille mémoire & temps de calcul) pour prévenir l’utilisateur et ne pas mettre a genoux le serveur. Hervé propose de réfléchir à une file d’attente en mode asynchrone.
• multi-thread, besoin de multithread pour accélérer nfft d’après Ferréol et Eric, Laurent B n’est pas sur que ca fasse une grande différence. Dans tout les cas pas besoin de cluster car on serait dominé par les temps de transfert (sauf pour MCMC ou si on propose d'avoir plusieurs job sur une grille de paramètres)
• Gilles indique que le JMMC a financé une grosse machine à Nice pour SUV mais elle pourrait être utilisée pour LITPro / OImaging

CDD Gilles mentionne que le JMMC a de l’argent pour payer un CDD, mais il est difficile de trouver quelqu'un de performant et le temps pour intégrer tous les concepts peut consommer une bonne partie de son temps. Ferréol pense que des parties autonomes comme la génération de modèle direct pourrait être confiées à un CDD. Michel (discussion après la fin de la réunion) propose de payer un stagiaire pour comparer les solution avec lmfit, genfit et un MCMC sur des données de test. Cela permettrait à la fois de vérifier les erreurs sur les barres d’erreurs et d’estimer les ressources de calcul nécessaires.

Rentrée Sept. 2018

Participants : Guillaume, Laurent B, Isabelle, Michel, Gilles, Eric, Hervé, Ferréol

Ordre du jours

• Déterminer et ordonner les actions prioritaires en vue du 'run' de septembre/octobre de l'équipe technique.

Compte rendu

Softs équipe technique :

• OItools
  • Fonctions de filtrage OK (Selection, merge, copy),
  • OItools CLI interface: https://github.com/JMMC-OpenDev/OITools/wiki/Command-line-interface
  • OItools specs (Vincent): voir JmmcOIFitsToolsVJB
  • Documenter (wiki) / consolider fusion INSNAME, (établir une liste des INSNAME référençant le même instrument/mode)
  • Revoir filtrages supplémentaires: (longueur d'onde) https://github.com/jsy1001/oifitslib/blob/master/src/oifitslib/oifilter.c
  • Regrouper les T3 et les V2 correspondant au moins si la différence de mjd est inférieure au DIT.
• Aspro2
  • Ajout de fonctions de rotation/scaling pouvant être réutilisées
• OIfits:
  • Bien afficher un warning si les mjd des T3 et des V2 diffèrent.
  • Se rapprocher des consortia / ESO pour qu'ils fournissent de OIfits2 valides.

Base de test

• appel lancé à GRAVITY
• données des TPs
• données des beauty contest
• https://github.com/jsy1001/oifitslib/tree/master/testdata
• ( un repertoire existe sur le serveur JMMC mais pas ouvert car pas sur que tout soit publique ).

LITpro

• problème de timeout avec Genfit
  • passage vers service asynchrone
  • écrire un log à chaque itération contenant tout le nécéssaire pour redémarrer genfit
• parallélisations possibles
  • MPI utilisable avec yorick
  • benchmark pour voir quelles sont les parties intéressantes à paralléliser.
• passage XML vers Image-OI
  • plusieurs questions: 1 oifits versus 1 oifits + 1 xml + ... , définitions des keywords

OImaging

• MiRA dans OImaging
• Adapter la GUI aux options de MiRA (hiérarchie)
• Sortie MiRA = table vis complexes:
  • qui doit faire la conversion vers V2 / T3 ? (la GUI? , l'algo (voir code Gilles pour WISARD)
• Améliorer l'ergonomie de la GUI
• Reprendre l'analyse et proposition sur normalisation des inputs + parametres pour l'interface algo/GUI (mail JSY 14/07/2018)

Points pour septembre / octobre (à compléter et ordonner)

1. Se rapprocher des consortia / ESO pour qu'ils fournissent de OIfits2 valides (Gilles)
2. Regrouper les T3 et les V2 avec OItools (Laurent Guillaume)
3. Ticket sur les pb de timeout pour discuter de la solution (Hervé, Laurent, Guillaume, Michel)
4. Benchmark parallélisation genfit (Hervé)
5. Ticket / page wiki définir le passage XML / Image-IO de LITpro (Michel, Guillaume, Laurent, Ferréol, Isa)
6. Base de données (Ferréol)
7. MiRA -> OImaging (Ferréol, Eric + Guillaume et Laurent pour option GUI et Gilles pour la partie V -> V2)

Priorités

Les points le plus urgents sont 7, 2, 3, 5. Pour ce qui concerne MiRA les lyonnais comptent venir à Grenoble fin septembre.

Une autre réunion model fitting est à prévoir en octobre peut être.

Ferréol Guillaume et Laurent feront le point chaque mardi à 11h.

2 mai 2018

Participants : Guillaume, Laurent B, Isabelle, Michel, Gilles, Eric, Hervé, Ferréol + André, Laurent M et Jacques par Visio

• 10h accueil + café
• 10h30 — 12h30 Model Fitting (discussions + atelier)
• 12h30 — 14h00 repas
• 14h00 — 15h00 Visioconf avec André Laurent M et Jacques sur la partie Image Reconstruction et OImaging
• 15h00 — 16h30 Atelier Image Reconstruction

Points à aborder:

• Model Fitting (LITpro)
  • User models
  • Acces au fitter génétique via l'interface
  • Exécution en ligne de commande

• Image Reconstruction
  • MiRA dans OImaging
  • PAINTER dans OImaging

Compte rendu

Voici un compte rendu synthétique (lapidaire?) de ce qui s'est dit. Les tâches à accomplir sont numérotées avec #..

• Equipe technique / OIFitsExplorer
  • #T1 distribution de la rustine de conversion du nom de la table OIFlux de GRAVITY + autres colonnes non standard
  • filtrage des OIFits avec OItools / OIFitsExplorer :
    • #T2 selection target /insname/ config,…
    • #T3 regridding des OIfits pour avoir des V2 pour tout les T3
  • #T4 Warning dans les logiciels pointant vers le filtrage
  • #T5 Fonction de création de la table OI_FLUX à partir d'un fichier externe de SED

• Model Fitting:
  • Fitter locaux
    • #F1 batterie de test: reprendre les TPs pour tester les perfs des fitter
    • #F2 nouveau fitter (BOBYQA)
  • Fitter globaux
    • #F3 GenFit (ajout dans l’interface)
    • #F4 enlever sniffer map étoffer plot Chi2 (redefinir un nouvel onglet pour présenter les résultats)
  • #F5 User functions
  • #F6 OIfits2
  • #F7 sortie OImaging
  • #F8 communication avec OImaging
  • #F9 Barres d’erreur
  • #F10 Effets instrumentaux (smearing, saturation dans VEGA)

• Image Reconstruction
  • #R1MiRA: sortie de l’image + table V(u,v,\lambda) modelisés
  • #R2 Sparco : ajout dès que MiRA est dans OImaging soit sous la forme d’une option à MiRA ou d’une méthode SPARCO/MiRA
  • #R3 OImaging : fonction convertissant V(u,v,\lambda) modélisés en ‘vraie’ sortie OImaging
  • #R4 PAINTER ; ajout dans OImaging
  • #R5 Ecriture OIFits2 en Julia

• Planning à cours terme (d’ici fin septembre)
  • #T1 (Laurent B?)
  • #T2 (Guillaume & Myriam, à voir suivant les autres points d’OIFitsExplorer sur lesquels ils veulent avancer.
  • #F1 (Ferréol)
  • #F2 (Ferréol)
  • #F3 (Hervé + Guillaume) rapidement si c’est simple, en septembre sinon
  • #F4 (Guillaume + Isa + Michel) à voir si ca rentre en septembre
  • #F5 (Michel aimerait le faire en ligne de commande pour l’école VLTI) pas avant septembre pour la GUI avec Guillaume
  • #R1 (Eric)
  • #R2 (Eric + Jacques +Ferréol) invitation de Jacques à Lyon pour le faire
  • #R3 (Gilles)

• moyen terme : le reste

6 février 2018

Participants : Guillaume, Laurent B, Isabelle, Michel, Gilles, Eric, Hervé, André, Laurent M, Ferréol

• Etat des lieux des activités récentes (en lien avec les anciens groupes Model Fitting et Image Reconstruction)
  • • Guillaume: interfaces LITpro, OImaging
    • Laurent B: OImaging
    • Isabelle: LITpro (user function)
    • Michel: LITpro (fitter & user function)
    • Gilles: WISARD (maintenance, OImaging)
    • Eric (CNAP): Lecteur OIfits2, Bandwidth smearing dans MiRA
    • Hervé (CNAP): LITpro (algo génétique)
    • André: maintien PAINTER
    • Laurent M: Expertise
    • Ferréol: vient d'arriver donc rien de concret au JMMC cette année

• Etat des lieux logiciel
  • • OImaging: WISARD (Gilles) et BSMEM seulement
    • LITpro: le plus utilisé mais ne lit pas les OIFITS2
    • MiRA: la version yorick lit/écrit les OIFITS2
    • PAINTER: des utilisateurs demandent des infos mais pas vraiment de retour constructif, pas visible depuis le JMMC

• Feuille de route
  • Court terme
    • LITpro: ajout des user-model avec un site web de partage, ajout d'opérateurs de transformation explicite pour limiter les items dans les menus
    • MiRA: ajout du bandwidth smearing, ajout dans OImaging
  • Aspect polychromatique (Aucun logiciel du JMMC ne fait de polychromatique).
    • LITpro: la variété des modèles polychromatiques possibles empêche de les ajouter dans LITpro (qui propose seulement les principaux modèles avec corps noir) d'où l'intérêt des user-models qui permettent de combiner des modules sans avoir pléthore de briques. Besoin de ré-écrire la structure interne des données pour prendre en compte plus simplement les longueurs d'onde.
    • PAINTER: manque l'écriture de OIFITS2 pour l'inclure dans OImaging. Eric propose de le faire dans le cadre du passage de MiRA à JULIA. Ensuite ajout sur le site du JMMC?
  • A plus long terme
    • LITpro:
      • proposer des nouveaux fitters (fit global),
      • methodes MCMC pour estimer les covariances et les afficher,
      • élaborer une batterie de tests pour évaluer les fitter.
    • Convergence des interfaces des logiciels
      • ajouter une sortie au format OImaging à LITpro pour avoir les mêmes outils de visualisation,
      • utiliser OImaging comme frontal unique?
      • avoir un bouton dans LITpro permettant de charger une image dans OImaging qui servira comme prior ou point de départ
      • via un notebook Jupyter
    • Synergies point de vue code:
      • Beaucoup de languages: yorick, IDL, JULIA. Or la partie gestion de données, lecture/écriture représente une part importante du code.
    • Modèle open source
      • Une partie des codes sur GitHub: PAINTER, MiRA, OImaging
      • Quelques nettoyage avant de rendre LITpro disponible
      • Mettre tous les softs dans l'organisation JMMC sur GitHub (avec OItools,...)?
    • lien avec AMHRA, réfléchir à relier LITpro avec la base de données AMHRA.

• Priorités:
  • Ferréol pense qu'étant donné le faible nombre d'observations avec une couverture suffisante pour faire de la reconstruction d'image, il est peut être plus intéressant de mettre l'accent sur le passage au polychromatique de LITpro et propose de passer plus de temps sur ce point.
  • Michel pense qu'il faut progresser sur la reconstruction d'image polychromatique, en particulier sur la prise en compte des visibilités différentielles, car c'est le meilleur moyen d'identifier les phénomènes dynamiques dans les objets, et que produire des images est le meilleur moyen pour pousser à augmenter la couverture (notamment par des télescopes supplémentaires).

• D'un point vue général (Gilles étant parti au mmoment de cette discussion) il y a peu d'interactions constructives entre les concepteur/mainteneur de logiciel et des utilisateurs. Cela rend difficile l'établissement de priorité. Guillaume propose d’insérer ce problème dans un sondage des utilisateurs du JMMC.