Sprint 1 slot roadmap 2018 Sept/Oct - MFIR

Suivi en version Wiki en attendant un prochaine version par board (github?)

Actions retenues

Ergonomie OImaging

1. [] générer une image de départ
   • [] en wrappant l'outil imgen de John Y. python comme un webservice (UWS)
   • [] depuis LITPro
2. [] permettre un enchainement pertinent entre plusieurs runs
   • [] gerer les 'nombreuses' images de resultats (nomenclature)
   • [] afficher les bonnes infos en cas d'erreur
   • [] repartir d'une solution passée
   • [] permettre le nettoyage de runs mauvais

Intégration des logiciels dans OImaging

1. [] MiRA
   • [] traiter la gestion des parametres depuis ImageInputOI en plus des options CLI
   • [] développer le panneau du GUI avec les spécificités MiRA
2. [] Gestion des parametres dans le GUI
   • [] gerer les suivi et l'integration de plusieurs logiciels avec leurs parametres specifiques
   • [] supporter le passage d'arguments supplémentaires non couverts par le GUI. A traiter avec John Y. dans la boucle.

Interaction en mode pas à pas GUI<->logiciels d'analyses

1. [] mode interactif LITpro algo génétiques
2. [] mode interactif OImaging

Retro 1 - mardi 11 sept

More... Close

• Validation des points à retenir pour le prochain sprint:
  • Améliorer l'ergonomie du GUI d'OImaging

• • Intégrer MiRA
  • rendre pilotage LITpro en mode interactif (pas à pas/ suivi de log / suivi de progression/reprise sur état)
    • la problématique est aussi présente sur l'interactivité d'OImaging en mode client/serveur
  • cf Actions Retenues pour le détails et suivi

• Gilles indique que Wisard s'en sort bien avec les ré-associations T3 V2 (cf mail du TBD ) : moins de pression sur regriding

D'ici la prochaine rétro:

• [X] prendre contact avec AMHRA pour préparer le couplage technique des outils début 2019
• [X] rajouter OImaging sur le wiki trac : http://trac.jmmc.fr/jmmc-sw/report
• [] cf les tickets existants lien vers le ticket interaction GUI 943-945

Items en cours:

• Gestion des parametres dans le GUI / gerer les suivi et l'integration de plusieurs logiciels avec leurs parametres specifiques
  • revoir les widgets WISARD / BSMEM, comment généraliser (hard-code) ?

Refactoring à faire pour définir des dictionnaires de mots clés (common, wisard, bsmem, mira ...) en dérivant de ParameterFitsTable (templates) ... et simplifier leur gestion dans le GUI (add/remove keywords meta / values)

• • voir document ERIC / JSY: description des parametres (https://bitbucket.org/noresources/ns-xml/wiki/program + tableur mail 18/07/2018 16:14) + partage des classes dédiées dans depot github ?

Retro 2 - jeudi 20 14h

Points discutés:

• Ferreol a repris la main pour gerer la gestion des parametres par oifits
• [ ] Ferreol clarifier le point sur l'init img (en reregardant le standart) pour qu'un fichier de sortie soit entrée du run suivant
• cas des fichiers OIFITS gravity:
  • pb de variance v2 differentiel etc ... -> à spécifier pour arriver a sortir ce qui est irréaliste / probleme de canal camera Gravite
  • [] creer un ticket pour conclure sur les règles à implementer (inclure Myriam)
• comment reutiliser les OUTPUT_IMAGE_PARAM ?
  • comme paramètres d'entrée libre (sauf chi2 par ex...)
  • réécraser une valeur d'entree avec ce qui sort
  • pas clair -> on reporte
• description des interfaces par parametres:
  • Laurent propose de retourner au auteurs des softs / le help + Output params
  • remettre en avant le help des softs (cf cookbook JRA)
  • cas du soft support ou il faut rajouter une image
  • positivité des parametres d'entrée
  • [] mettre un pointeur vers le code du traitement metier pour les classes du GUI
  • peut-on / doit-on avoir 2 niveau de parametres suplementaires (mode expert) ?
    • NON on commence par ceux obligatoire
  • params de base à mettre systematiquement : FOV, taille pixel npsteps, regul
    • basculer les parametres "commun" que WISARD ne gère pas dans BSMEM

Items en cours: * supporter le passage d'arguments supplémentaires non couverts par le GUI

• • quick look: OK pour transmettre un parametre supplémentaire dans UWS (job) puis passer ce parametre à la commande à executer.

Attention au format (split String) donc tester les caractères spéciaux (-, espace) et tester la sécurité (& ; ...) en passant par un shell (bash pour wisard-ci)

• • BUG UWS service: configurer le nettoyage des fichiers temporaires (input/output) et la durée de retention des jobs / fichiers + mettre en place un zombie killer ...

Retro 3 - mardi 25 11h

• accès SVN vers les classes gérant les keywords specifiques
• Downscaling des images intégrée dans OImaging (ca aiderait Wisard qui perd de l'info)

Propositions d'algo à discuter:

• Format simplifié d'Entrée des données, basé sur ce qui est fait dans WISARD:

*le format dériverait de celui décrit §5.2.3 (page 23) de http://www.mariotti.fr/doc/approved/JMMC-MAN-2500-0001.pdf (utilisé dans WISARD) *la dimension du champs FREQS_U de la structure donne le nombre de télescopes. Une structure par unité de temps, le nombre de télescopes simultanés pouvant changer d'un temps à un autre. jamais moins de 3 télescopes. *Implémentable directement en byte stream si on reste dans un univers intel big endian IEEE, en stream xdr sinon, ou au pire en table fits. *pas de flags mais VIS2ERR < 0 = flaggé. *Extension possible en polychromatique, en rajoutant 1 dimension spectrale à tous ces éléments de structure, en précisant le nombre de canaux, et en rajoutant les champs VISPHI, VISPHIERR. Probablement qu'une table de lambda ne serait pas inutile mais ferait double emploi avec les FREQS.

• Format simplifé de sortie; celui de la section 5.4 du même document. Equivalent à ce qu'on a mis en place avec Eric pour la sortie de MIRA pour OImaging.

• Algo utilisé dans WISARD pour remettre en face les T3 et les V2:

Expériences acquises:

Liens entres T3 et V2

TBD

Mode interactif

TBD