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

Base de données de test

Réunions

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)
• 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écéssaires sont presentes dans le GUI et que les plots vont bien (Hervé & Guillaume)
• tests (tous)
• régler les tickets qui pourraient être résolus facilement (tous)

Guillaume est pret à 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 à regler / améliorations à faire:

• Verifier la sécurité (execution 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 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 interogé au fur et à mesure par le GUI,
• que faire lorsqu'il y a plusieurs fichiers d'entrée (comment ecrire la sortie?)
• comment gerer les données flaggée bad data par LITPro
• homogénéiser les plots.
• OIFITS2

Une partie des ces problemes (flag, fusion de fichier, selection) sont commun à 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.