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)
    • [X] afficher les bonnes infos en cas d'erreur
    • [X] repartir d'une solution passée
    • [X] 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 : code java accessible par SVN
    • [] supporter le passage d'arguments supplémentaires non couverts par le GUI. A traiter avec John Y. dans la boucle.
    • [] supporter le passage de params de type image

Gestion des paramètres d'images

  1. [] FOV scalling rotation : pour modifier dans le GUI les images transmises

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

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

Retro 5 mardi 16 oct.

Ergonomie OImaging

  • proposition de changer max iter
    • [] confirmer le passage de 200 à 20 ?
  • [] gérer les paramètres de type images
  • MiRA et Wisard peuvent maintenant etre appelés par le GUI avec une input_image de taille nulle <=> pas d'image

Intégration des logiciels dans OImaging

  1. [] MiRA - FS
    • [] traiter la gestion des parametres depuis ImageInputOI en plus des options CLI
    • [] développer le panneau du GUI avec les spécificités MiRA

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

il faut que les logiciels sortent en output les criteres pour continuer à enchainer ou pas (affichage visuel dans le GUI). [] proposer de rajouter un critère de convergeance pour indiquer

divers

  • L'optimpack de wisard est un peu ancien. La version legacy en ligne ne fonctionne plus avec IDL
    • [] les Lyonnais regardent ce point
  • [] Gilles rappel que les données de la binaire sont bien publiques car se sont de calibr

Retro 4 à confirmer mardi2 oct.

  • PB messagerie à Lyon, rdv loupé

Retro 3 - mardi 25 11h

MiRA:
  • début de page MiRA pour décrire les parametres
    • cf topic OImagingParam
    • TOTVAR doit être supporté même s'il existe des équivalents
    • [] Ferreol fini d’identifier les keywords à intégrer au GUI/OI_IMAGE_INPUT_PARAM
    • mettre la conf initiale dans le mode ou les resultats sont au tops (ex. mode bootstrap)
  • mira-ci est déjà géré en conf sous oimaging-uws-server/runtime/docker/bin/mira-ci
    • [] Guillaume donne le lien svn
  • [X] Laurent verifier l'annulation du batch mira (trap)
  • accès SVN vers les classes gérant les keywords specifiques

  • Intégrer le downscaling des images dans OImaging ?
    • ca aiderait Wisard qui perd de l'info (sur le cas des binaires par ex.)
    • on pourrait se base sur le travail initié par Laurent sur Aspro2
    • cela est reporté sur l'image de départ si l'on ignore le NO_MIN -> même approche que BSMEM
    • MiRA fait ce travail aussi avec des SPLINES avec normalisation
    • -> Oui le GUI doit faire ces traitements en les affichant (export fits a faire aussi).
  • quid de Optimpack nvelle version vs ancienne ?
    • Ferreol Utilise la version legacy (avec wrapper Matlab) même si certains cas ne sont pas aussi bien traités que dans la nvelle version, est + éprouvée que la nouvelle
    • de nouvelles methodes ont été rajoutées, mais pas trivial d'utilisation ou pour traiter des pb a plus petites dimensions.
    • personne n'a encore commencé à écrire de wrapper

Question:

  • faut-il généraliser le mode bootstrap (recentrage dans le champs/ seuillage après quelques itérations) ?
  • est-ce que le GUI ne peut pas faire ce travail ? (avec par ex. recentrer + multiplier le nombre de pixesl)

Bonne pratique retenue:

  • les logiciels devraient logguer l'ensemble des parametres utilisés dans l'algo:
    • on sait donc qui gagne entre options ou keywords de table
    • on sait quel traitement sont appliqué ou non sur les images
    • une implementation possible ( ou déclinaison ) est de sortir ces informations dans OI_OUTPUT_PARAM

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 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
  • [] FS : relire 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)

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

oi input params

  • l'input image n'est plus nécessaire (on peut en fait laisser une taille nulle).

utilisation du champ libre input param

  • utile pour les cas avancés
  • a ne laisser que sur les versions beta une fois bien rodé
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2018-10-16 - GuillaumeMella
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback