Tags:
view all tags
Cette page liste les minutes également diffusées par mail au sein du groupe. %TOC% ---+ 14 Janvier 2013 <verbatim> *Participants* : Gilles, Guillaume, Laurent, Sylvain, Michel et Isa + Eric pour les points 2 et 3. de 10h à 16h env. au CRAL Ordre du jour: 1- Status de LITpro / besoins des utilisateurs. Réorganisation de la bibliothèque de fonctions géométriques : homogénéisation avec Aspro possible ? 2- introduction sur le démarrage du développement de l'OifitsExplorer 3- mise à disposition d'un environnement Yorick qui s'installe au mieux sur toutes les plateformes : comment procéder ? _____________________________________________________________________ *1. Status de LITpro / besoins des utilisateurs* La bibliothèque actuelle est une liste d'objets qui commence à être longue avec certaines fonctions modèles qui se ressemblent mais qui sont différentes pour l'ajustement même, comme par ex. l'ellipse qui est décrite par elong_disk, nonorm_elong_disk, flatten_disk, nonorm_flatten_disk, fonctions qui diffèrent entre elles par les paramètres à fitter ou les bornes de ceux-ci. Réduire cette multiplicité semble difficile car elle répond à un besoin. Le GUI peut présenter des fonctions génériques et des jeux d'options (polaire, allongé, applati, etc.) à l'utilisateur. En dessous, le CLI peut proposer des fonctions pour toutes les combinaisons possibles ou une fonction qui compose elle-même des fonctions élémentaires. Néanmoins, le nombre de fonctions est rapidement démultiplié, notamment avec la convolution par une gaussienne, la multiplication par un corps noir, etc. Pour autant, toutes les combinaisons ne sont pas pertinentes. La bonne réponse est de donner la possibilité de construire des fonctions utilisateurs ou "User Function" (UF dans la suite du texte) Le GUI peut montrer une fenêtre pré-remplie à l'aide d'un template et quelques accès faciles à des exemples au travers d'un wiki où l'on peut copier/coller des exemples à modifier selon les besoins. Le CLI est conçu pour cela : par exemple l'ordre des paramètres des fonctions est indifférent (géré par le code). Cela permet tous les changements de variable possibles, et de traiter simplement des problèmes complexes comme : - tache sur un disque (limite d'un paramètre dépendant d'un autre paramètre (la tache ne doit pas sortir du disque). - ajustement d'orbite. Pour celui-ci, un travail est à faire côté LITpro : Hervé a envoyé ce qu'il fallait; reste à permettre la prise en compte de la variable temporelle (prévu dans le code mais pas opérationnel). Remarque de Gilles : il faudrait permettre la prise en compte des vitesses radiales. Réflexions de Michel (post-réunion) : "ajuster en même temps les vitesses radiales est un outil très puissant pour les orbites. Mais il ne suffit pas de lire un fichier. Il faut aussi que le modèle calcule les vitesses radiales, ce qui n'est pas vraiment possible si le modèle ne retourne que la TF de l'objet. Il faudrait que le modèle retourne aussi des vitesses radiales, et que des données vitesses radiales soient simulées, et que le chi2 général soit augmenté du chi2 sur les vitesses radiales. Bref cela me semble mission difficile..." Pour la prise en compte de la SED (fichier extérieur) dans ces UF : cela a été fait en mode CLI (cf. article SPIE). Des fonctions d'import de données spectrales utilisables par le code pourraient être fournies, entre nous au départ en tous les cas. Ensuite, on verrait quel standard sortira. Il me semble néanmoins nécessaire de procéder par étapes, la première étant de se limiter à des UF sans fit simultané de la SED, pour valider le processus. Il n'a pas été dressé de planning mais il serait bon d'initier sous peu le processus, sur une version de développement du GUI actuel, qui va de l'appel à un wiki,l'ouverture d'un template pour écrire la fonction jusqu'à la compilation de la fonction modèle avant le fit. Pour tester la procédure, on peut prendre une UF simple (une fonction de la biblio. avec un paramètre différent par ex.). Les aspects sécurité sont discutés : - utiliser une boîte à sable -sandbox- (le code yorick peut lancer des commandes systèmes). Semble a priori le plus simple. - modifier yorick pour interdir certaines commandes. Cela semble lourd à mettre en place et demande un travail récurrent lors des mises à jour de yorick. - utilisation d'un meta-langage. Le code CLI autorise les fonctions utilisateurs de même nom que les fonctions de la bibliothèque, sans que ces dernières soient écrasées. A noter : les UF une fois utilisées par leurs auteurs devraient pouvoir être accessibles aux autres utilisateurs (via le wiki correspondant); cela implique probablement la rédaction d'un commentaire explicatif dans l'UF par l'utilisateur. Parallèlement à ce développement côté IPAG, les actions à mener côté CRAL sont, outre l'implantation du travail d'Hervé et une ré-écriture de la bibliothèque de fonctions modèles : - implanter le fitter Nelder_Mead (afin de progresser sur la recherche du minimum global) - ce dernier ne calculant pas de barres d'erreur ni la statistique sur les paramètres, il appellera à la fin de son ajustement, le fitter standard pour que soient déterminées ces valeurs indispensables: barres d'erreur, matrices de corrélations. - décider avec Guillaume de l'update de la version actuelle du GUI qui propose l'option "avec fit" pour l'exploration de l'espace des chi2 (fonction lp_chi2_probe en lignes de commande). (implique aussi mise à jour de la doc.) Un point est fait sur l'organisation / tickets : A la question "faut-il separer les tickets usersupport de ceux des groupes ?", en ce qui concerne le groupe ModelFitting : le choix est de rester en copie des demandes support utilisateur de manière à pouvoir participer aux réponses. (et le faire ss forcément "attendre" que le ticket soit affecté nominativement). Dernier ticket en date : celui de M. Hillem, à traiter (act. I & M). Remarque de Michel : ce serait bien que l'utilisateur puisse accéder aux tickets existants avant de soumettre le sien. Cela avait été pensé mais non mis en place : le choix fait jusqu'à présent est que Myriam opère un premier traitement des tickets en regardant les tickets existants et reprenne les mêmes réponses si tickets analogues. -------------------------------------------------------------------------- *2- Introduction sur le démarrage du développement de l'OifitsExplorer* Exposé de Guillaume sur OifitsExplorer, Oifits2 et la base de données Oifits - OIfitsExplorer - mise à disposition ou non de la fonction binning ? Michel signale que le binning des données a un effet statistique sur les barres d'erreur. Il suppose implicitement que le modèle est constant sur les coordonnées des données du groupe binné. En principe, il vaut mieux faire la moyenne sur le modèle courant. Il faut au moins avertir l'utilisateur. Le binning peut être utile pour la visualisation, mais dégradant pour l'ajustement. - OIfitsExplorer = outil de sélection des données A noter : pour LITpro, il est prévu de fournir un outil pour sélectionner un sous-ensemble des données et de pouvoir activer/désactiver les données à la volée lors d'un ajustement. - OifitsExplorer pourrait devenir un outil de correction (avec suivi des problèmes de version d'instruments, nécessité de l'info 'date', et avec nettoyage (en combinant par ex. plusieurs critères dans des expressions booléennes) - Oifits2 : cf. http://www.jmmc.fr/twiki/bin/view/Jmmc/OIFITSTwoProject ) En dehors de problème d'identification et de références croisées, il y a des infos manquantes vis-à-vis : - des visibilités différentielles (bornes des bandes spectrales prises pour le calcul des intercorrélations) - de la résolution spectrale. Les besoins se font de nouveau sentir et des échanges devront arriver dans l'année. Un draft de version 2 pourrait émerger dans l'année et les personnes s'étant manifesté seront informées sur ce travail. - Oidb L'idée initiale de base de données réduites est en lien direct avec le format OIFITS. Des demandes ont déjà été faites pour élargir aux données interférométriques n'ayant pas encore été réduites. D'après Eric, la communauté internationale est demandeuse et il ne faut pas hésiter à recueillir les besoins très largement. Souhait d'Eric : la base de données ne devrait avoir que des fichiers "valides", avec historique, ce qui semble raisonnable si l'utilisateur a à sa disposition un outil d'exploration de données et que lui sont proposés des moyens de corriger si pb. Question d'Eric : la library java nom.tam.fits supporte-t'elle les entiers 64bits ? Réponse par Guillaume après la réunion : oui, d'après le code et comme indiqué ici: http://fits.gsfc.nasa.gov/fits_64bit.html Pour ces développements sur le format OIFITS pour lesquels l'intérêt est grand, info d'Eric (PI du WP4 "Interferometric Image Reconstruction" du nouveau JRA d'Opticon) : le JMMC va être doté très prochainement de 68 keuros (soit ~2 FTE) pour justement ce travail. Notification également de 15 keuros à JBLB, donc total pour l'IPAG de 83 keuros : ces développements sont donc possibles quasiment dès maintenant ! ------------------------------------------------------------------------ 3- mise à disposition d'un environnement Yorick qui s'installe au mieux sur toutes les plateformes : comment procéder ? divergence de vue entre les 2 groupes : - le groupe de réalisation propose de coordonner les efforts puisqu'il est impliqué dans la livraison du pipeline Amber avec Yoco (http://ipag.osug.fr/twiki/bin/view/Ipag/Distrib/YoCo). Cela aboutirait à délivrer un package LITpro. - le groupe AIRI (resp. de l'équipe : Eric) préfère garder la maîtrise de la distribution des logiciels qu'il développe, dans un souci de visibilité de l'extérieur mais aussi de facilité (Eric pour son enseignement installe Yorick+yeti+plugins nécessaires sur les machines de ses étudiants). On peut regretter cette divergence, mais pour l'instant aucune action n'a besoin d'être lancée. Consensus sur le fait de se tenir informé de part et d'autre des évolutions réalisées. Question d'Eric : que manque-t-il à fits.i par rapport au plugin cfitsio ? On l'ignore et peut-être une comparaison pourrait-elle être menée. Par qui : ? ---------------------------------------------------------------------- Fin de réunion précipitée suite à l'oubli d'un impératif sur l'horaire de retour. Pas de date associée aux actions listées. Celles-ci vont se faire au mieux compte tenu du plan de charge de chacun. Pour le groupe Model Fitting même : pas de réunion du groupe prévue dans l'immédiat car il faut d'abord à mon avis que les actions LITpro-CRAL citées plus haut aient avancé significativement. Par contre, circulera un mail au sein du groupe avec demande d'avis et d'aide pour mise en circulation de la version beta actuelle. </verbatim> ---+ 19 Juin 2012 <verbatim> *Participants* : Guillaume, Laurent, Martin, Florentin, Armando, Michel et Isa de 14h à 15h30 ordre du jour: - discussion sur les tickets en cours - nouvelles fonctions modèles géométriques _____________________________________________________________________ *Revue des tickets en cours* Pour prendre connaissance de ces derniers, se connecter sur http://trac.jmmc.fr #260 Missing flatten / elongated models pour fonctions avec assombrissement centre-bord Décision : on peut combler ce manque même si cela n'a pas de sens (équations établies avec hypothèse de la symétrie radiale) J'aurais néanmoins aimé une justification scientifique et non un souci d'homogénéisation des fonctions. Action : Isa #266 Graphe de clôture de phase pas OK Le plot est correct s'il est issu de LITpro, avec néanmoins une mauvaise résolution, comme tous les autres plots du Plot panel, depuis que le zoom demandé a été effectué. Info donnée par Michel à Guillaume pour améliorer la génération des fichiers .png à partir du pdf, du pt de vue de la résolution et de la taille des fichiers. Une réflexion est en cours au sein de l'Equipe de réalisation sur la génération des plots, ceux notamment des données (via le projet du visualisateur de fichiers oifits http://www.jmmc.fr/twiki/bin/view/Jmmc/JmmcExpressionBesoinOifitsviewer). Elle aura une incidence sur les graphes de LITpro. En attendant, la légende de l'axe des abscisses des plots de T3amp et T3phi issus de File Panel est à modifier --> ajouter (max of the 3 frequencies) Action : Guillaume #276 Amelioration des affichages dans le GUI - echelles #277 Amelioration des affichages dans le GUI - identification Ces 2 tickets sont à merger et demandent encore de la réflexion pour améliorer l'exportation des données et du modèle. Il serait néanmoins possible en attendant de permettre une sortie .tsv comme c'est le cas pour d'autres plots du GUI, en s'entendant sur le format. A voir. Action : Guillaume / Michel #304 Problème en chargeant des fichiers AMBER en cours. Florentin doit envoyer une archive de ses fichiers posant pb. #308 'Plot Image' limites en suspens : pas de solution évidente "automatique" pour éviter le repliement de champ, quel que soit le modèle. En attendant d'en trouver une : parler de ce pb dans les FAQ et dans le User Manual §1.5.5/ Plot Image et la seule solution actuelle pour l'utilisateur : replotter avec un plus grand champ. Action : Martin #134 Save plots in the settings file of the GUI L'utilisateur peut actuellement sauver ses settings et choisir dans les Preferences si c'est avec ou sans les Results, le choix par défaut étant "sans". Les plots ne sont pas sauvés. Il est décidé que le choix par défaut soit "avec" et que le "Save settings..." du menu soit changé en "Save..." avec choix proposé à l'utilisateur, avec 2 boutons : - bouton présélectionné "Embed results" - bouton désélectionné "Embed plots" Action : Guillaume et Martin (pour répercussion dans la doc) *Nouvelles fonctions modèles géométriques* Elles sont présentées dans le fichier ci-joint(reunion-190612.pdf). Discussion sur : - la possibilité de regrouper les fonctions par "famille" les elong_, les flatten_ et les stretched_ - la possibilité de remplacer elong et flatten par la fonction stretched avec indications données en help : si l'utilisateur veut un elong_ par ex., il doit borner inférieurement stretch_ratio à 1, et borner supérieurement stretch_pos_angle à 180 degrés. - la possibilité de remplacer les fonctions stretched_modulated_func (avec func=circle ou gaussian_ring) par inclined_func avec comme variable sini ou i. La discussion n'a pas vraiment eu de conclusions tranchées. Je propose pour la prochaine beta release de mettre les fonctions stretched telles que, et opérer seulement le changement pour stretched_modulated (minimisation des chgts et de la doc). Action Isa La présentation dans le GUI des fonctions par classes (au lieu de la longue liste actuelle) peut se faire à tout moment, mais ce n'est pas urgent (Action : Guillaume) Ont été présentées quelques fonctions 'corps noirs", qui n'ont de sens à être utilisées que si la SED est également fittée. Ce n'est pas la priorité pour le GUI actuel qui ne peut avoir en entrée que des fichiers au format OIFits. Néanmoins des informations quant à des exemples d'outils VO manipulant des SED sont donnés par Guillaume à l'issue de la réunion : ASDC: http://www.asdc.asi.it/tutorial/SEDBuilder/SEDBuilderTutorial.html GOSSIP: http://cosmos.iasf-milano.inaf.it/pandora/gossip.html VOSED: http://sdc.laeff.inta.es/vosed/index.jsp IRIS: http://cosmos.iasf-milano.inaf.it/pandora/gossip.html (mentionne des formats supportés par les outils VO: http://cosmos.iasf-milano.inaf.it/pandora/gossip.html) Service CDS : http://cdsweb.u-strasbg.fr/news.php?fn_mode=fullnews&fn_incl=0&fn_id=236 (il faut jouer sur l'url des exemples de l'article pour rentrer le nom de l'etoile puis ca fonctionne bien avec topcat ou VOspec par exemple) NED : http://ned.ipac.caltech.edu/forms/photo.html (doit fournir des SED, mais je n'arrive pas a le faire fonctionner...) Le message (http://www.ivoa.net/forum/sed-dm/2011/000002.html) mentionne le data model SED qui n'est pas encore encore finalisé, mais probablement deja bien avancé pour servir de base. Le DataModel Spectrum lui plus ancien est considéré comme un recommendation et mentionne les SED : http://ivoa.net/Documents/latest/SpectrumDM.html Enfin, la fonction lp_chi2_probe, 1D ou 2D, a été présentée par Michel. Elle peut être implantée dans la beta release du GUI, de manière similaire à lp_chi2_slice. Le pb de son utilisation peut venir du temps de calcul nécessaire. L'utilisateur doit prendre des précautions bien indiquées dans le Help. Prochaines réunions : en automne si avancée notable dans les tests de la beta release mise à dispo courant juillet. réunion sur fitters et fonction orbite, également à la rentrée avec les mêmes conditions. </verbatim> ---+ 30 Mars 2012 <verbatim> Minutes de la réunion du 30 mars 2012, Téléconférence 10h00-11h40 *Participants* : Martin, Denis, Nicolas, Guillaume, Sylvain, Laurent, Michel et Isa *odj annoncé* : discussions sur le GUI: - bilan / beta-version actuelle : version 1.0.11b9 - besoins/critiques identifiés - idées/réponses à ces besoins - mise à jour de la doc Points menés en parallèle pdt la réunion, reportés différemment dans ce compte-rendu ______________________________________________________________________ *Au préalable* : remarques sur la doc. actuelle Martin a mis à jour le User Manual lié à la version publique actuelle (merci à lui!). Commentaires de Laurent : - le manuel manque de captures d'écran. Celles-ci en fait illustrent seulement le tutorial. Identifier les endroits où une capture d'écran serait utile (action Laurent) - plus penser à l'interopérabilité entre LITpro et Aspro2. Ce dernier utilise déjà les fonctions modèles de LITpro. Le GUI-LITpro pourrait peut-être mieux bénéficier de ce qui est fait pour Aspro2 : à préciser sur cas concrets (cf. plus loin sur le changement de coordonnées cartésiennes/polaires) *Bilan sur la version 1.0.11b9 avant de la rendre publique* *Rque préalable* : pour tester les versions en développement, il faut avoir comme URL (déclarée dans Preferences/General : http://jmmc.fr/~betaswmgr/LITproWebService/run.php) Bug apparent : le bouton "default preferences" inactif TO DO : éviter de pouvoir lancer différentes applications en développment (mais j'avoue ne pas avoir compris le pb réel ni la solution de Guillaume ;-) ) *Changements effectués par Guillaume / version publique actuelle* *A noter* : '--> doc' signifie une répercution de mise à jour sur la doc. 'TO DO' signifie 'à faire' pour la version suivante, n'empêche pas la mise à disposition de la version beta actuelle - affichage du résultat d'un fit dans le Result panel & le Personal Notebook, égal exactement à la sortie de la fonction lp_show_fit - Plot Chi2 : ° le mot "sampling" a été changé en "#samples", plus explicite --> doc ° deux 'checkbox' ont été ajoutés pour permettre le tracé des chi2 réduits, ainsi que le choix de l'échelle logarithmique. --> doc - Show selected tables, dans File panel pour afficher les .fits, il faut dorénavant avoir lancé Topcat (ou tout autre lecteur de fichiers fits). Un message est donné pour l'indiquer à l'utilisateur. On peut lancer topcat sans avoir à relancer LITpro. --> doc Mais peut-on éviter cette action de l'utilisateur ? probablement losqu'on aura progressé sur la lecture/édition des fichiers oifits. - Correction d'un bug dans l'affichage des vis2 après fit dans les fichiers .tsv (colonne des erreurs erronée) - Plot UV Map : ajout de plots et d'une animation entre eux A été décidé de : ° supprimer le plot 'uv_model' ° faire apparaître, au lieu de uv_model_data.png et uv_model_data_edges.png, un court texte explicatif ° grossir le plot (d'un facteur 1.5 à 2?) bug à lever : frequ. spatiales maximales des maps incorrectes (TO DO action M&I) --> doc TO DO : permettre à l'utilisateur de : - zoomer, en Z et spatialement - sauvegarder le(s) plot(s) en un format .fits - Bibliothèque des modèles géométriques : ajout d'une fonction disk_polar = idem que la fonction disk mais en coordonnées polaires (rho, PA) bug à lever (action Guillaume) + syntaxe à changer : dans le tableau Parameters du Target panel, mettre à jour le menu contextuel activé sur les valeurs des paramètres rho et PA : "This model is located at x=' ' and y=' ' relatively to the center of this target." (modifier la syntaxe également pour les paramètres x et y : "This model is located at rho=' ' and PA=' ' relatively to the center of this target.") (_chgt de syntaxe proposé en rédigeant les minutes, pas pdt la réunion_) TO DO : généraliser ce changement de coordonnées aux autres fonctions Ce changement est proposé sur le Target Editor/Models du GUI d'Aspro2. Peut-on / doit-on adopter la façon adoptée sur Aspro ? i.e. ajout sous le tableau des paramètres des fonctions modèles sélectionnées de boutons "x/y" et "rho/PA" à cocher ? ce serait souhaitable (souci d'homogénéisation des GUIs Aspro et LITpro), mais pour ce pb particulier, il est préférable de permettre un changement de coordonnées par brique (alors qu'il est global pour Aspro) : ajouter ces boutons sur la ligne "Add model" semble une bonne alternative. *+ Améliorations à apporter sur les plots des OI-data, ainsi que des Results (plots effectués par Guillaume) :* - changer le range des ordonnées par défaut : le fixer entre le min(0, min(données)) et le max(1, max(données)) pour les VIS2 et T3amp et min(-180, min(données)) et le max(180, max(données)) pour les T3phi, l'utilisateur pouvant ensuite zoomer/dézoomer (--> doc : indiquer comment zoomer/ dézoomer) - simplifier le codage des couleurs : actuellement une couleur par Table, préférer une couleur par fichier - TO DO : changer la légende qui apparaît à droite des plots en indiquant plutôt le nom des fichiers (mais cela impliquerait de garder une distinction entre les différentes Tables...). Voir côté couche yorick si cela est aisé à faire. - TO DO : permettre une sauvegarde des Plot Image, UV Map, Radial avec ou sans model en un format qui permette à l'utilisateur d'afficher ensuite à sa guise ( format .fits par ex.) - TO DO : décider de l'allongement/ aplatissement des fonctions d'assombrissement centre-bord qui n'aurait rien de physique (les fonctions existantes étant issues d'une approche analytique à symétrie radiale) - pas de décision nette pdt la réunion si ce n'est attendre une demande plus explicite d'utilisateurs -. *Conclusion :* - consensus pour que la version 1.0.11b9 soit rendue publique (une fois les actions sur le Plot UV Map réalisées) - cela peut devancer la mise à jour de la doc, qui doit naturellement suivre de peu (action Martin : délai 15-20 jours OK ?) </verbatim> ---+ 27 Mars 2012 <verbatim> Minutes de la réunion du 27 mars 2012, Téléconférence 10h05-10h50 Participants : Hervé, Guillaume, Gilles, Laurent à l'IPAG, Michel et Isa au CRAL Absent : Florentin Ordre du jour initial : point sur les actions décidées lors de la réunion du 24 janvier 1- point sur les fitters à implanter dans LITpro : un code génétique (Hervé), un recuit simulé (Florentin) 2- implantation d'une fonction "orbite" (Hervé) Seul le point 2 a été discuté. ______________________________________________________________________ Depuis la réunion du 24 janvier, pas d'échange entre Florentin et Hervé quant à la comparaison d'algos génétiques sur un jeu de données qui était à determiner. Hervé s'est initié à Yorick en écrivant une fonction "modèle d'orbite". Cette fonction a 7 paramètres : demi grand-axe, période, excentricité, inclinaison, passage au périastre, angle omega, angle OMEGA. Ces 2 angles sont connus à pi près. La variable "temps" indispensable pour fitter une orbite, présente dans le format OIFits (MJD = Modified Julian day = UTC moyen de la mesure), est prévue dans LITpro mais doit être "activée". Actions : - envoi par Hervé de sa fonction orbite à Lyon, ainsi qu'un ou deux jeux de données OIFits pour tester; - travail sur le code LITpro pour fitter ces données avec cette fonction (Isa et Michel). Des interactions auront certainement lieu, par téléphone ou mail mais hors liste de diffusion. - On peut fixer une réunion comme celle d'aujourd'hui une fois le fit réussi pour voir l'implantation de la fonction orbite dans le GUI (date à fixer, probablement fin mai-début juin - je ferai un doodle prochainement). Il se peut que, selon les données, le fitter actuel ne soit pas toujours le mieux adapté pour un fit d'orbite. D'où l'intérêt, à l'avenir, de disposer de différents fitters. Pour le point 1 : attente de la réunion du 30 mars qui est plus dédiée aux améliorations des plots du GUI, mais si Florentin est présent, nous ferons un point sur son action. </verbatim> ---+ 24 Janvier 2012 <verbatim> Minutes de la réunion du 24 janvier 2012, Observatoire de Lyon, 10h-17h Participants : Florentin, Hervé, Guillaume, Michel, Isa Objectifs: implantation dans LITpro de fitters différents du fitter standard actuel =trfit (Levenberg-Marquardt avec régions de confiane et gestion des bornes) ________________________________________________________________ **présentation de LITpro, CLI et GUI** (Michel) Hervé ne l'ayant jamais utilisé. au cours de cette présentation, émergent ou ré-emergent les actions suivantes : - écriture d'une fonction "orbite" qui pourrait être un module au même titre que les fonctions géométriques. (action Hervé) à tester ensuite sur des données temporelles (sur des données simulées avec Aspro2 ou sur un jeu de données avec variation temporelle (cf données JBLB, Florentin, Sylvestre ? -tbd- ) ) - permettre l'implantation, de façon dynamique, de fonctions utilisateurs : l'utilisateur aurait un template via le GUI pour écrire, en yorick, sa fonction; elle serait compilée (retour des erreurs éventuelles) avant application, sur les données sélectionnées, comme tte fonction de la bibliothèque. Serait proposé à l'utilisateur de partager sa fonction qui serait alors mise sur une page web. (action ... futur recruté CNAP ? ;-) ) **présentation de l'interface - "cahier des charges" pour les nouveaux fitters** (Michel) à partir du document ci-après, mis sous cvs : interface_with_fitters.txt **discussion sur l'évaluation des barres d'erreur, sur l'apport des méthodes MCMC** (Hervé) - sur ex. de l'estimation d'une orbite : l'orbite résultat du meilleur fit (i.e. meilleur chi2) n'est pas forcément l'orbite la plus probable. - réflexions sur l'évaluation des erreurs de fit : actuellement, l'évaluation repose sur l'hypothèse d'une courbure symétrique du chi2 autour de la solution. - Il serait vraiment utile de proposer plusieurs méthodes d'évaluation des barres d'erreur. **présentation d'un code génétique** (Florentin) à partir d'un script d'algorithme génétique écrit en Yorick en 2007 et appliqué à une gaussienne (extrait de YoCo - http://ipag.osug.fr/twiki/bin/view/Ipag/Distrib/YoCo -) décidé : envoi de ce programme à Hervé pour qu'il compare avec ce qu'il fait de son côté en matière de code génétique et qu'il s'initie à yorick. Idéalement, Hervé et Florentin devraient comparer leurs codes sur un même jeu de données, à déterminer. Florentin a également testé un algo. de recuit simulé, et l'a comparé à trfit sur des données AMBER (ref. papier ?). Pourquoi ne pas utiliser ce jeu de données pour tester les algos génétiques ? tbc. A faire : écrire cet algo. de recuit simulé en tenant compte de l'interface avec LITpro décrite pdt la réunion. **conclusions** : - Création d'un compte pour Florentin et Hervé sur avae, la machine de l'équipe AIRI où se trouve l'archive cvs de LITpro. (action faite/ transmission des passwd par téléphone (Michel)) L'écriture d'autres fitters ne devrait impliquer aucun changement dans les autres modules du soft, étant donné l'architecture et l'interface adoptées. - écriture d'un fitter "recuit simulé" (Florentin) - écriture d'un fitter "génétique" (Hervé) N'a pas été discutée la façon de suivre les développements effectués mais il me semble naturel d'utiliser simplement la messagerie via la liste de diffusion (pour l'archivage facile des échanges), même si cela peut gêner les autres membres du groupe non directement impliqués sur le sujet. Une réunion (télé- ou visio-conf) peut être programmée une fois les tests avec différents fitters effectués et avant la mise en place du widget "fitter" dans le GUI, avec la doc associée. Cette réunion pourrait avoir lieu en *avril* -tbc, sondage doodle à lancer-. __________________________________________________________________ interface_with_fitters.txt Interfacing fitters ------------------- @ 1/ General contraints and needs @ 2/ Naming and organisation @ 3/ fitter itself @ 4/ Display of results @ 5/ Communication with modeler, available functions @ 6/ Open points @ 7/ Modifications of this document 1/ General contraints and needs ------------------------------- - The interface is essentially: -> get the values of the parameters from the modeler (start) -> get the residuals (and chi2) from the modeler. <- send back the values of the parameters. Various tools (functions) are available, for instance to get informations on the parameters (see later). - The computation of residuals lasts from a fraction of a second to many minutes. As much as possible, we must save the number of computations of the residuals... - A fitter must be allowed to call another fitter. For instance: o A fitter is looking for the global minimum by using a fitter that only dives in local minima. o A fitter can find a minimum, but relies on another fitter to determine errors on the parameters, correlation matrix, statistics, etc. - Parameters can be vectorial. This is handled internally by the software. The fitter only sees one set that gathers all the parameters to be fitted. 2/ Naming and organisation -------------------------- - A fitter has a unique name (preferably short), "<fitname>". o Now defined: - "standard" = "trfit" - "trfit" - "nlfit" - "Nelder_Mead" (airi) - Corresponding software can be loaded by including file "LITpro_fitter_<fitname>.i" In production, this file is included only when necessary, when the corresponding fitter is actually used. - Two functions must be defined: o lpf_<fitname>_go(world, keywords=, ...) o lpf_<fitname>_show(world) These functions will be called by user functions lp_go_fit and lp_show_fit. - To authorize a new fitter just add it to the list: h_set, LPF_FITTER_NAMES, <fitname> = "60 chars of description"; The GUI may use lpf_go_fit_list() to get the list of the fitters and associated description. 3/ fitter itself ---------------- lpf_<fitname>_go(world, keywords=keywords, ... key=val, ...) - inputs o world is the opaque object where everything is stored. o keywords that must be accepted: verbose - gives some information during the fit. Generally not used during production. Essentially for experts. No output is allowed if verbose=0. itmax - max number of iterations. One iteration corresponds to a successful step, with a chi2 improvement. plot - (naming should change...). A reference on a user function to be called between two iterations (see after). o Other specific keywords can be defined. When useful for the user, the keywords can be made available to the user in lp_go_fit. o Specific keywords for "trfit" (that could be used by other fitters if approximately the same meaning). tol_step= - Tolerance on the smallest step. Each parameter is normalized by its scale (see lp_set_parameter). The fit is stopped if the norm of the vector of fitter parameters is less than TOL_STEP. Default is 1e-8. tol_gradient= - Tolerance on null gradient. Fit is stopped if the norm of the vector of derivatives of chi2 versus each parameter is lower than TOL_GRADIENT. Default is 1e-8. tol_degen= - Tolerance on the detection on degenerencies. Default is 1e-8. o Keywords can also be given through a hash table named "keywords": keywords |- verbose |- itmax |- plot |- tol_step |- tol_gradient `- tol_degen This way is the standard way. Function lpf_parse_keyword is useful for handling the default values of the keywords (see later). o Default values of the keywords must be defined by each fitter. - They may be optimized differently for each fitter (itmax) - This does not prevent to set defaults at the level of lp_go_fit. o Precedence of the keywords: - 1 - the value given with the keyword; if void, - 2 - the value found in keywords; if void, - 3 - the default value defined in the fitter function. This parsing can be easily done by using lpf_parse_keyword: itmax = lpf_parse_keyword("itmax", keywords, 200); (1) (2) (3) - Outputs o Returns a hash table (can be the fitter workspace). o Mandatory entries in this workspace : chi2 - final chi2. iter - number of iterations done. itmax - maximum number of iterations. - Specific behaviors and limitations o The fitter is requested to ask for the residuals in the current state of the parameters, before to change them. This is usually done to start the fit anyway. This will allow the user to know the change of chi2 before and after the fit. o "plot" user function must be called with argument world between two iterations. if (!is_void(plot) && is_func(plot)) { plot, world; } o A fitter can call another fitter directly, but must use functions lpf_fitter_go() and lpf_fitter_show() (see after). - Informations from the other fitter can be obtained by reading the returned hash table. o control-C The fitter can be interrupted with control-C. The signal must be catched (yorick function catch()) to save the current results like a normal exit with a limited number of iterations. The last obtained best parameters are loaded in world using lpf_set_fitted_parameter_values() (see [@5]). 4/ Display of results --------------------- s = lpf_<fitname>_show(world) This function is called by lp_show_fit. The output is a single string (several lines) to be displayed to the user either by the CLI of by the GUI. For now, the information to be displayed is: values of the parameters, standard deviations, correlation matrices. Sample from trfit: Stopping alibi: no significant change in parameter values (tol_step) Final values and standard deviation for fitted parameters: d1 = 2.0039 +/- 0.0164 d2 = 2.2654 +/- 0.0588 i1 = 0.77707 +/- 0.0523 i2 = 0.22293 +/- 0.0152 x2 = -16.389 +/- 0.0104 y2 = -8.9162 +/- 0.0155 --- Covariance matrix --- d1 d2 i1 i2 x2 y2 d1 2.7e-04 -4.3e-04 3.1e-05 -3.1e-05 -1.9e-05 5.1e-05 d2 -4.3e-04 3.5e-03 -9.2e-05 9.2e-05 9.9e-05 -1.2e-04 i1 3.1e-05 -9.2e-05 2.7e-03 7.8e-04 -5.8e-06 8.3e-06 i2 -3.1e-05 9.2e-05 7.8e-04 2.3e-04 5.8e-06 -8.3e-06 x2 -1.9e-05 9.9e-05 -5.8e-06 5.8e-06 1.1e-04 -4.4e-05 y2 5.1e-05 -1.2e-04 8.3e-06 -8.3e-06 -4.4e-05 2.4e-04 --- Correlation matrix --- d1 d2 i1 i2 x2 y2 d1 1 -0.44 0.036 -0.13 -0.11 0.2 d2 -0.44 1 -0.03 0.1 0.16 -0.13 i1 0.036 -0.03 1 0.98 -0.011 0.01 i2 -0.13 0.1 0.98 1 0.037 -0.035 x2 -0.11 0.16 -0.011 0.037 1 -0.27 y2 0.2 -0.13 0.01 -0.035 -0.27 1 5/ Communication with modeler, available functions -------------------------------------------------- The actions are mainly: - get/set the values of the parameters to be fitted, - get the weighted residuals, chi2. - parsing the keywords: itmax = lpf_parse_keyword("itmax", keywords, 200); We have see this in [@3]. - workspace ws = lpw_get_workspace(world, "<fitname>"); // get new workspace This gives an independent workspace that can be obtained again at next call. If useful, keyword "clean" allows the workspace to be empty (cleaned). If not cleaned a new call of the same fitter will get again the previous workspace. - get/set values of the parameters a = lpf_get_fitted_parameter_values(world); lpf_set_fitted_parameter_values, world, a; Only the values to be fitted are all stacked in the same vector. The fitting interface knows the correspondence with the actual parameters. Vectorial parameters are possible. --------------------------------------------------------------------- WARNING: setting a parameter out of the bound is not allowed => crash --------------------------------------------------------------------- The fitter must be sure to update the last (i.e. best) values of the parameters by using lpf_set_fitted_parameter_values(). - Vector of weighted residuals and chi2 res = lpf_compute_residuals(world); chi2 = lpf_compute_chi2(res); If necessary, getting the size of the array of the residuals is possible before to compute residuals, this way: nres = lpw_get_global(world, "number_of_data"); - Getting informations on the parameters. names = lpf_get_fitted_parameter_names(world) val = lpw_get_parameter(world, names(i)).<property> In names, there is a one-to-one correspondence with vector of parameter values. In case of a vectorial parameter, the name of the parameter is repeated as many times as the number of elements in the vectorial parameter. Properties: descr - (string) description of the parameter. flags - (long) flags. Autorized flags are: LPW_FLAGS_FIXED, LPW_FLAGS_VMIN, LPW_FLAGS_VMAX, LPW_FLAGS_AUTOSCALE. (flags & LPW_FLAGS_AUTOSCALE) => autoscale (scale not defined) (flags & LPW_FLAGS_VMIN) => has vmin defined (flags & LPW_FLAGS_VMAX) => has vmax defined (flags & LPW_FLAGS_FIXED) => not fitted parameter (*) (*) Since the parameters are fitted parameters here, this test is always FALSE. scale - (double) Typical magnitude of the parameter value if it is known. If void, an automatic scaling is used by the fitting algorithm for this parameter. units - (string) name of units (only informative). vmax - (double) upper bound for the value of the parameter. If void, no upper bound is defined for the parameter. vmin - (double) lower bound for the value of the parameter. If void, no lower bound is defined for the parameter. A property can be void if not defined. --------------------------------------------------------------------- WARNING: setting a parameter out of the bound is not allowed => crash --------------------------------------------------------------------- - Calling other fitters (requested in [@1]). fct = lpf_fitter_go(fitter_name) ws = fct(world, itmax=3) pb : nomenclature : lpf_get_fitter_go et lpf_get_fitter_show The first function returns a reference on the fitter function. If fitter_name is not given (or void), the standard fitter is used. lpf_fitter_go checks the availability of the fitter function and includes corresponding files if necessary. As any fitter, the hash table allows some information to be returned. The function can be called more directly this way, if used only once: ws = lpf_fitter_go(fitter_name)(world, itmax=3) The summary of the fit can also be obtained this way, for instance for appending the returned lines to the ones of the calling fitter. To be added in the function lpf_<fitname>_show(world). summary = lpf_fitter_show(fitter_name) 6/ Open points -------------- - Need for errors on the parameters, correlation matrix, etc. as shown in [@4]. Probably need to implement algorithms for this task. o trfit: use jacobian from the gradient computed from finite differences, with rescaling of error bars. o need for resampling methods ? - Control-C not yet implemented in trfit. If a satisfactory solution is yet to be validated. - If all the parameters are fixed, the GUI should ask the user to release at least one parameter when clicking on "run fit". </verbatim> ---+ 15 Juillet 2010 <verbatim> Minutes de la téléconférence du jeudi 15 juillet 2010 10h00/11h00 Participants : Martin, Denis, Guillaume, Michel, Isabelle Excusés : Sylvain, Gilles, Armando, Florentin Ordre du jour de la réunion : - nouvelles ramenées de SPIE, concernant le model fitting et le format OIFits, par Guillaume, Martin et la commission 54 de l'UAI par Denis - mise en ligne de la version de développement - actions en cours ou à mener _______________________________________________________________________ _Nouvelles ramenées de SPIE-San Diego - 27 juin-2 juillet_ o model fitting : RAS o format OIFits : des discussions ont eu lieu dans le cadre de la commission UAI #54. A été décidée la remise en fonction d'un groupe de travail et l'activation d'une page Twiki pour collecter les besoins et échanger sur la question. En fait, en regardant le site de la commission (http://olbin.jpl.nasa.gov/iau/), la motivation pour un tel groupe figurait déjà : Working Group on Intererometry Data Standards The near-term goal of the working group is to develop enhancements to the OIFITS data exchange standard, in particular: 1) Standardise and incorporate existing practice into the standard; 2) Prioritise enhancements that would benefit a broad cross-section of the optical interferometry community; 3) Represent the interests of the major facility optical interferometers. Le groupe figurant dans : http://www.mrao.cam.ac.uk/research/OAS/oi_data/ va sans doute voir arriver Gilles. o commission C54 UAI : pas de retour sur l'outil Iper (motivé par un besoin soulevé par cette commission l'an dernier). La commission a principalement travaillé sur les projets liant USA et Europe, et mis en place les prix Fizeau et Michelson. _mise en ligne de la version de développement_ Après discussion, au sujet des plots : on laisse comme c'est. La redondance ne nuit pas... et on verra à l'usage. Plot Chi2 en log ou linéaire : Modification proposée par Guillaume, et acceptée, pour éviter que l'utilisateur ait à cliquer log ou pas : avoir 2 boutons distincts "Plot Chi2" et "Plot log(chi2)". Bug relevé en séance (et corrigé ensuite) : l'échelle du plot chi2 1D n'est pas la bonne. Question, fondée, de Denis : à quand, dans les Acknowlegments, un papier à referee, A&A par ex. comme pour Search Cal ? ==> ajout d'une action dans le parag. suivant _actions en cours ou à mener_ o correction du bug du same insname prévue pour la rentrée o interaction client-serveur : - chiffrer le gain en zippant le fichier de données - réaliser le packaging complet (GUI + LITpro + Yorik + lib) pour plateforme Unix. o rédaction du rapport d'activités (2007-2010) et de prospectives. Le conseil du JMMC se réunissant le 19 octobre, il est décidé de faire circuler dans le groupe fin août-début septembre une première version (rédigée par ITB) et que l'on se réunisse la première quinzaine de septembre pour faire le point et finaliser. La partie "bilan" ne devrait pas poser pb, la partie "prospectives" demandera certainement plus de réflexions (qui continue ? et pour faire quoi?). On peut en effet considérer que la version que Guillaume va mettre en ligne d'ici peu restera fondamentalement stable, avec probablement quelques améliorations suite à la remontée d'utilisateurs : il faut donc songer à la suite (dévelopement d'un LITpro2 ?) o traduction en anglais du TP de Porquerolles pour le mettre sur le site (cf. minutes de la réunion précédente) action ITB o rédaction d'un papier à soumettre à A&A (action ITB) avant la fin de l'année _Prochaine réunion_ première quinzaine de septembre. à fixer avec un doodle. </verbatim> ---+ 21 Mai 2010 <verbatim> Minutes de la téléconférence du vendredi 21 mai 2010 10h00/11h00 Participants : Guillaume, Sylvain, Olivier, Martin, Armando, Michel, Isabelle Excusés : Denis, Gilles Ordre du jour de la réunion : - Point sur l'utilisation de LITpro et Iper - Bilan de l'école de Porquerolles : o enrichissement du tutorial o modifications/améliorations de certaines fonctions ces 2 points entrainent une action sur la documentation - restructuration des plots du GUI (différenciation nécessaire entre les plots par TARGET et les plots globaux) - interaction client-serveur (à optimiser) - implication ds le groupe de F. Millour _______________________________________________________________________ _Point sur l'utilisation de LITpro et Iper_ http://jmmc.fr/~swmgr/LITproWrapper/log/ est la page où sont comptabilisés les appels à certaines fonctions (dont runDiskFit pour Iper) Reste à pouvoir identifier l'origine de des appels (action de Guillaume en cours) _Bilan de l'école de Porquerolles_ il est positif car il a permis de progresser côté soft et côté tutorial. Le site de l'école sera bientôt ouvert (action Olivier & Guillaume) incluant les présentations et les ateliers. A été émise, et acceptée, l'idée d'Olivier d'insérer, sur la page LITpro, un item "Exercices" où seront mis les exercices de l'école, comme présentés pdt celle-ci : sous la forme d'énoncés "guidés" succintement, avec, à part, les solutions, et sous la forme détaillée (traduction du guide en anglais -action Isa). (afin de gagner du temps, on prend l'ex. 4 tel qu'il a été présenté; il semble en effet inutile de changer les sets de données, l'important étant plus la conduite du fit que le résultat) L'exercice 4 ne sera pas l'Exemple 4 du Tutorial : pas assez différent de l'Exemple 3 (binaire également avec seulement en plus l'adjonction de la fonction "background"). Par contre, on peut compléter l'Exemple 3 des demo settings avec la fin de l'exercice 3 (ajout des T3phi) (action Armando). Les principales modifications apportées au soft avant et après l'école ont été répercutées sur le GUI (--> version beta 1.5b3) http://jmmc.fr/~mella/LITpro/ Elles impliquent des modifications dans le Users manual (action Martin). (A noter (oubli pdt la réunion) : nouvelles fonctions à insérer ds le manuel : les nonorm_* (disk, elong, flatten) et background) Est décidé d'insérer un paragraphe sur la normalisation (dans §1.5.4 ?) qui pourrait être accessible via un bouton help placé au niveau de la check box de "Normalize total flux". Rédaction du parag. : action Michel? Est revue en séance la liste des modif. apportées par Guillaume : * The USAGE messages of the LITpro engine are now displayed as error. It makes some error messages much more clear. * Set the user info field with a post-it-like background super ! - a été décidé de renommer User info : "Personal notebook" - pour aller plus loin dans le souci que l'utilisateur se retrouve dans ses fits successifs, qui sont automatiquement incrémentés : faire apparaître le Personal notebook, non seulement dans le "Settings panel" mais aussi dans le "Result panel". L'utilisateur peut éditer ses propres notes après le résultat automatiquement édité. L'idée de dénommer différemment les "Fit Result n" est rejetée du fait de la difficulté ensuite de déleter. * Fix behaviour on parameters editing. User does not have to validate using enter key. * The widgets of the chi2 plots have been changed to be more intuitive nouvelle visu OK ! (reste peut-être, oubli d'en discuter en réunion, le changement du titre : Plot chi2 panel --> ? Slices in the chi2 space * One checkbox allows to plot the chi2 slices or the log(chi2) Reste à répercuter dans le GUI le fait de pouvoir afficher les N premiers minimums trouvés par chi2_slice (N=6 par défaut). Ces valeurs pourraient être affichées à côté du plot. * The bounds values of the chi2 parameters are changed on every parameter change * Add one header to the TSV exported files and errors are given instead of minimal and maximal values. * The angle of radial plots is displayed in the label presented into the left tree and can get decimals _restructuration des plots du GUI_ Une différenciation est nécessaire entre les plots par Target et les plots globaux. Actuellement, par ex. il n'est pas possible de visualiser le Plot Radial de plusieurs Targets; plot Chi2 est dans le Target panel alors qu'il est global. Une réflexion est à mener qui devrait aboutir à un nouveau Plot panel. Pour rappel et aide à la réflexion, tableau récapitulatif des différents plots et de leur status / Target : Function plot_ // Choix de Target // All Targets // List_Targets [Target_i,Taget_j] baselines // oui // oui -par défaut- // oui uv-coverage // oui // oui -par défaut- // oui radial // oui // oui -par défaut- // oui radial_model // oui // oui -par défaut- // oui image // oui // non // non // - à spécifier- par défaut 1er Target uvmap // oui // non // non // - à spécifier- par défaut 1er Target chi2_slice // non // non // non conceptuellement, fit global. On ne fitte pas par Target sniffer_map // oui // non // non actuellement // par défaut 1er Target // rendre ce choix possible _interaction client-serveur_ à optimiser pour gagner en rapidité - soit les données sont mises sur le serveur (temporairement) mais pb de confidentialité - soit package "Yorick+LITpro+lib." transmis au client idées pouvant améliorer les choses indépendamment de l'option prise : - utilisation de machines "miroirs" de celle du JMMC (lieux à déterminer) - zipper le fichier de données : le gain peut être manifeste ! Avant d'agir, Guillaume a besoin de donées quantitatives : lui transmettre les cas où on est coincé par le temps d'exécution (fichier .xml, données sur la machine, la liaison, etc) _implication ds le groupe de F. Millour_ Unanimité pour que le groupe accueille qqun d'aussi actif que Florentin. Donc bienvenue à Florentin ! --> l'ajouter sur la liste Consensus également sur la priorité à mettre sur l'implantation de différents fitters et l'optimisation globale. --> prendre contact avec lui (Isa & Michel) _Prochaine réunion_ en juillet (semaine du 12 au 16). à fixer avec un doodle </verbatim> ---+ 19 Mars 2010 <verbatim> Minutes de la téléconférence du vendredi 19 mars 2010 14h00/15h00 Participants : Guillaume, Sylvain, Olivier, Denis, Martin, Armando, Michel, Isabelle Excusé : Gilles *Ordre du jour de la réunion :* - lancement d'Iper - point sur la liste d'actions sur page Twiki (mettre priorités) - besoin de permettre une brique avec tache - prepa TP de l'Ecole de Porquerolles : choix de l'exemple à ajouter au tutorial existant. - besoin de plus d'explication sur la normalisation ? _______________________________________________________________________ *lancement d'Iper* Guillaume a inclus les dernières remarques. Il est clair que l'outil n'est pas parfait : il permet un fit avec une valeur initiale du diamètre fixée. L'utilisateur peut donc tomber sur un minimum local. Idéalement, il faudrait un fit plus robuste, composé de fits initiés différemment, le meilleur étant donné comme résultat final. Ce peut être fait à terme. En attendant, il est décidé de lancer l'outil tel que, avec ses limites en sachant que LITpro peut aider l'utilisateur à mieux fitter ses données. Remarque post-réunion : peut-être peut-on rajouter, en revenant à la ligne après "opened" : For the fit, the initial value of the diameter is set to zero. For other initial values, use LITpro. Il est décidé de lancer Iper en debut de semaine prochaine, avec le texte qui a circulé et été corrigé sur la liste. *point sur la liste d'actions sur page Twiki* cette page est : http://ipag.osug.fr/twiki/bin/view/Jmmc/JmmcModelFittingActionList La priorité a été mise sur la sortie en format fits des plots (image et uvmap). Guillaume a déjà fait des essais. Avec cette sortie, on perd l'orientation et les coordonnées. A l'utilisateur de s'en débrouiller en se référant à l'image donnée sur le GUI. Proposition de Guillaume : adjoindre les coordonnées WCS ? Pas de réponse nette en réunion. Elle mérite d'être essayée. *Quid d'un modèle d'une brique avec tache* Des fits avec des données VEGA ont fait remonter le besoin de pouvoir fitter sans considérer le flux total par brique, mais le flux local, de manière à permettre de fitter une tache (par ex. un disque) sur par ex. un autre disque. L'implantation d'un modèle "disque avec amplitude constante" est possible dans LITpro, de même que les autres fonctions géométriques, pour la TF desquelles on n'a plus flux_weight mais une amplitude. Reste à trouver le nom de ces familles de fonctions, ou plutôt le préfixe, comme elong_, ou flatten_ pour les fonctions circulaires allongées ou aplaties. Action : Denis et tous Propositions post-réunion : nonorm_func (pour no-normalized function) ... *Préparation du TP de l'Ecole de Porquerolles* choix de l'exemple à ajouter au tutorial existant o données AMBER : binaire avec des flux variant en bande H et K et environnement circumstellaires résolus. TARGET : HD87643 Papier de référence: http://www.aanda.org/index.php?option=article&access=bibcode&bibcode=2009A%2526A...507..317MPDF F. Millour a fourni 4 sets de données qui serviront "de fil rouge" à l'école. Olivier va sélectionner parmi eux une dizaine de fichiers qu'il mergera en un seul, pour le model fitting. Dès que c'est fait, l'envoyer au groupe pour qu'on puisse mener le fit (de la même manière que les premiers exemples du tutorial) ... ou le mettre sur la page de partage des données. o fit avec des données MIDI, par souci d'équité : Olivier a un set de données de bonne qualité sur lesquelles un fit par un disque, ou une gaussienne devrait marcher. o set de données simulées avec ASPRO avec par ex. une brique éclipsant une autre : abandonné, faute de temps. Mais avec les 2 nouveaux sets de données, adjoints aux 3 exemples du tutorial, on devrait avoir suffisamment de quoi occuper les étudiants durant un apres-midi. Les encadrants de cette séance pratique seront : Michel, Olivier, Guillaume, Sylvain, Gilles, et Tijl Verhoest, Florentin Millour, Antoine Mérand ("formés" au début de l'école). Préparation d'un support écrit (Isabelle). *besoin de plus d'explication sur la normalisation* Remarque de Guillaume : "pour les cas simples de combinaison de briques comme on a actuellement, le fait de pouvoir normaliser ou pas semble indépendant du fit. Pourquoi alors doit-on cliquer On ou Off avant de fitter ?" La méthode implantée se veut générale et applicable notamment pour des futurs modèles polychromatiques. Mais il est vrai que si l'on se restreint aux briques actuelles, on pourrait simplement faire en sorte que la somme des poids soit égale à l'unité. Mais déjà, implanter une brique non normalisée (point ci-dessus) ne permettrait plus une méthode aussi simple. Pour l'instant, après discussion, on ne modifie pas l'aide à ce sujet : on verra après l'école, suivant les interrogations des étudiants. *Prochaine réunion* en mai après l'école. à fixer avec un doodle </verbatim> ---+ 12 Février 2010 <verbatim> Minutes de la téléconférence du vendredi 12 février 2010 10h00/11h10 Participants : Guillaume, Gilles, Alain, Martin, Armando, Olivier, Michel, Isabelle Excusé : Denis Ordre du jour de la réunion : - bilan des premiers mois d'utilisation publique - améliorations prioritaires côté LITpro (pbs "same INSNAME", same "TARGET", legendes plots, ...) côté GUI (plot VIS2 pour fichiers VEGA,...) - insertion de l'outil "Fit par un UD" --> discussion sur la page web (remarque à la base : la page est déjà "dense", comment l'alléger, la clarifier pour que l'utilisateur voit de suite ce qu'il peut faire : fitter par un disque ou fit plus complexe) - prepa TP de l'ecole de Porquerolles : ex. supplémentaire / tutorial ? lequel ? *************************************************************** *bilan des premiers mois d'utilisation publique* pas de statistiques précises disponibles : Guillaume a trouvé un outil pour les estimer mais qui est difficile à utiliser. Les utilisateurs semblent être majoritairement les membres du groupe et des membres "périphériques" (collaborateurs via VEGA, ou MIDI). Un seul utilisateur étranger s'est manifesté : Leonard Burtscher. La plupart de ses remarques ont contribué au point suivant. *améliorations prioritaires* *côté LITpro* - erreur "same INSNAME" à supprimer : action tjrs d'actualité (I&M) - erreur "same TARGET" : après discussion sur le choix entre "suppression du test", "mise d'un warning "attention, param toto different", "augmentation des écarts tolérés sur l'alpha et le delta"", la décision est prise de : ° garder le test et 1 arcsec de tolérance ° mettre un warning ° permettre à l'utilisateur de ne plus afficher ce warning (sinon il faudrait à chaque fois cliquer OK sur la fenêtre warning qui s'ouvre) (Guil & M) - /plots de uvmap et image ° donner l'échelle des couleurs (I&M) ° permettre un export en format fits : ainsi, l'utilisateur pourra faire ce qu'il veut avec ses outils (contours, autre échelle, etc) (Guil &M) Remarques : - ce format doit être lisible directement par ASPRO -(post-reunion): il serait bien de permettre cet export en fits aussi pour UVmap *côté GUI* - le bug du plot des vis2 et résidus pour les données à une seule mesure par fichier (données VEGA, MIDI-Burtscher) a été fixé par Guillaume (dû à un probleme de conversion entre un tableau yorick de taille 1x1 et les structures xml). Il sera corrigé ds la prochaine release. - sera également effectué ds cette version le déplacement de la colonne "standard deviation" à côté de la colonne "value" pour faciliter la lecture. - a été amélioré le support des proxy (pb d'utilisation à partir de sites protégés) -(post-réunion- oubli-) : questions à conserver ° comment sont gérés les flags ? sur les données de Burtscher (vis MIDI = visamp et visphi), seules les visamp sont gardées or, ds le File Panel, ce sont les visphi qui sont cochées. ° si ds un fichier, à la fois qques visamp et qques visphi sont flaguées, comment l'affiche-t-on ? *Insertion de l'outil "Fit par un UD"* - des tests sont nécessaires. (tous les membres du groupe) Chacun est invité à opérer 3 tests en partant de : http://jmmc.fr/~mella/LITproWebService/fitDisk.html et faire part, via la liste, des pbs rencontrés. - insertion de l'outil sur le site / allègement de la page LITpro proposition : ° ajouter ds § Data Analysis (table des matières de http://www.jmmc.fr/) sous LITpro : Fit Unif Disk (Guil) ° le clic sur "Fit Unif Disk" ouvre la page actuellement égale à http://jmmc.fr/~mella/LITproWebService/fitDisk.html ° les résultats s'ouvrent sur une page une fois le fit lancé qui invite à utiliser LITpro pour un fit plus complexe. ° sur la page LITpro : déplacer vers le haut le widget LITpro, sous le titre, pour mieux le mettre en évidence. (Guil) (c'est un essai; la page est dense en texte; peut-être renvoyer la Documentation sur une page annexe... à voir) - une fois les tests effectués et validés, et l'implantation réalisée, une annonce sera faite via Olbin et ForumHra. (I) *Preparation des TP de l'Ecole de Porquerolles* Il serait bien d'enrichir le tutorial avec d'autres fits. idées : - binaire avec des flux variant en bande H et K et environnement circumstellaires résolus (à partir de données AMBER - contacter F. Millour (Olivier) - set de données simulées avec ASPRO (G&0) avec par ex. brique éclipsant une autre - fit avec des données MIDI, par souci d'équité (O ?) *Point discuté suite aux interventions de L. Butscher* Question : comment MIDI calcule ses estimateurs ? Reference donnée par Olivier ... à lire pour y voir plus clair : author = "Jaffe, Walter J.", title = "{Coherent fringe tracking and visibility estimation for MIDI}", booktitle= "New Frontiers in Stellar Interferometry", series = "SPIE Conference", city = "Glasgow, Scotland United Kingdom, June 21-25", editor = "W. A. Traub", volume = "5491", publisher= "Society of Photo-Optical Instrumentation Engineers, Bellingham, WA", pages = "715", year = "2004" 2 logiciels existent pour la réduction des données MIDI : EWS et MIA, mais leur produit final n'est pas systematiquement un fichier à la norme oifits. Le groupe support du JMMC a aidé à analyser les problèmes des fichiers de Burtscher pour les rendre lisibles par LITpro. Walter J et Leonard B ont utilisé le validateur de fichier OIFITS pour modifier EWS. *Point oublié lors de la réunion* issu des tests avec données VEGA : / plot radial model : LITpro permet de plotter suivant l'angle de coupe. Il serait bien que le GUI le permette aussi mais après que l'on ait introduit un codage en couleur des "theta" des mesures (chaque mesure a ds le plan uv des coordonnées (r, theta) mais ds le plot, ttes les mesures sont vues ds un même plan; il faut donc pouvoir les distinguer entre elles et pouvoir tracer le modèle en faisant varier theta (égal par défaut à 0) (I&M puis Guil.) *Conclusion* un bilan des actions définies devrait être fait d'ici 3-4 semaines. --> prochaine réunion à fixer via doodle ou studs (I) </verbatim> ---+ 11 Septembre 2009 <verbatim> Minutes de la téléconférence du vendredi 11 septembre 2009 10h00/11h10 Participants : Guillaume, Sylvain, Laurent (CDD Equipe technique du JMMC), Martin, Armando, Olivier, Denis, Michel, Isabelle Ordre du jour de la réunion : dernière réunion avant la mise à disponibilité. donc déterminer les actions à effectuer pour l'ouverture. - Point sur le GUI - Point sur les docs : Tutorial, Users Manual, Présentation et Animation - Point sur la page web Model Fitting - Point sur la page web de partage des données - Organisation pour et après l'annonce de l'ouverture *************************************************************** *GUI* "petites" modifications : - supprimer les demo settings actuelles - remplacer par celles du tutorial, en les dénommant tutorial_set1, tutorial_set2,... - remplacer theta par PA - (discuté après la téléconf) blocage de l'écriture dans les cases "Name" (ces cases étaient en effet éditables) La version livrée du GUI sera la 1.0 - on remet à plus tard l'introduction de la fonctionnalité "conversion [x,y] <=> [rho, PA]" celle-ci pourrait se faire via le menu Edit. Pour memo : - à plus long terme : bénéficier des plots des données développées pour ASPRO - à court ou moyen terme : permettre une sortie des résultats sous format fits et oifits. *Docs* Merci à Hervé pour ses commentaires. - Tutorial : RAS (corrections d'Hervé entrées par Guillaume) exemple 4 avec l'utilisation de sniffer_map différé. - Users Manual GUI (action Martin) : ° mises à jour des dernières modifications du GUI (Load remote files, menu contextuel des [xi, yi] (objet multiple) --> indication de [rho,PA], demo settings pointent ceux du tutorial, etc) ° glossaire : plutôt à la fin qu'au début comprend les mots apparaissant ds le GUI, et qui peuvent passer pour du jargon : target, settings, settings tree, target, VISamp, VISphi, VIS2, T3amp, T3phiu, v, flux_weight, chi2, degrees of freedom, covariance matrix, correlation matrix, ... Le renvoi à la page où est mieux défini le mot n'a pas été tranché, dépend de la compilation. Un simple label peut suffire. - Présentation générale LITpro (action Olivier) °prise en compte de certaines remarques d'Hervé : meilleure mise en évidence de la FAQ, du besoin de partir de plusieurs conditions initiales.. ° suppression de l'information sur la disponibilité du package "LITpro-GUI", celle-ci étant différée tant qu'il n'y a pas de doc LITpro - Animation ou "visual demonstration" (action Sylvain et Guillaume) décrirait dynamiquement (sans accompagnement vocal) le set 1 du tutorial. faisable d'ici quelques jours, donc livraison avec cette demo animée décidée. *Page Web http://www.jmmc.fr/modelfitting * - mise à jour avec les modifs suscitées - meilleure mise en évidence de "JMMC Public repository of OI-FITS files" --> l'enlever de "Related Links", ajouter un texte invitant les utilisateurs à partager leurs données (donner contact) *Page Web http://apps.jmmc.fr/oidata* L'idéal serait que l'on puisse sur les données que l'on confronte à LITpro (mais c'est sans doute souhaitable aussi pour celles utilisées pour la reconstruction d'image) avoir accès à un endroit où on pourrait mettre son propre rapport de fit, pouvoir regarder comment d'autres ont fitté, mettre en évidence des pbs, en résoudre d'autres, etc., et que cet endroit soit public. La réflexion est lancée. *Organisation pour et après l'annonce de l'ouverture* Compte-tenu des actions qu'il reste à effectuer, on peut songer à une ouverture au plus tard dans 2 semaines. L'annonce se fera par mail au forum_HRA, à Olbin et à la SF2A. Jeudi 17, aura lieu une teleconf. JMMC durant laquelle les modalités seront probablement définies. A définir également : un message que devra utiliser la personne obtenant avec le soft des résultats publiables. Et avoir comme objectif à court terme : la rédaction d'un article qui pourra être ainsi cité comme référence. Bref, du boulot sur la planche sans parler de la correction des bugs qui ne tarderont pas à apparaître... Les bugs devraient remonter via Hervé (Users support), qui peut opérer un premier fitrage si les erreurs rencontrées sont plus liées à une mauvaise utilisation du GUI, jusqu'à la mailing-liste du groupe. Après...il faudra répondre. Un premier bilan (sur l'utilisation du soft et notre réactivité) devrait se faire avant Noël. </verbatim> ---+ 12 Mai 2009 <verbatim> Minutes de la téléconférence du mardi 12 mai 2009 -9h30/10h45 Participants : Guillaume, Sylvain, Gilles, Martin, Armando, Olivier, Michel, Isabelle Ordre du jour de la réunion : - Point sur User manual, Tutorial - Point LITpro et GUI - Point sur la discordance sur les T3 entre ASPRO et LITpro - Actions à mener pour la livraison en juin - Organisation après la livraison Prochaine réunion : non programmée. S'il y en a une, ce pourrait être après qques mois d'utilisation par la communauté pour faire un premier bilan et identifier les besoins prioritaires. La R&D liée à la réalisation d'un LITpro2 (incluant par ex. les paramètres vectoriels, un meilleur fitter, etc) n'a pas été abordée. *************************************************************** *Documentation* Tutorial : l'exemple 3 (mise en évidence d'une dégérescence) est à rédiger, sans mettre le sniffer_map. "Réserver" ce dernier pour un exemple 4, à créer sur des données simulées avec ASPRO d'une binaire (point source centrée + gaussienne) avec une composante enfouie (point source de rapport de flux ~1/20) (action Olivier). Users manual : OK, restent qques points de détail, et mises à jour compte tenu des dernières modifications du GUI. *LITpro et GUI* Des améliorations sont à apporter au soft, comme permettre un même INSNAME lorsqu'on a à fitter sur plusieurs fichiers issus d'une même observation, visualiser de "vrais" disques (et non des disques apodisés) lors du plot_image d'une binaire de 2 disques, mettre le resultat du sniffer_map sur le plot même. Du côté du GUI, améliorer l'écriture des paramètres, indiquer "ascii" à côté de TSV, format proposé pour l'exportation des figures. *Problème des T3* Sur des données simulées avec ASPRO d'une binaire observée avec clôture, LITpro obtient une concordance entre les données et le modèle sur toutes les mesures sauf les T3. Pour avoir concordance, il faut que dans LITpro, on change le signe de la deuxième base (conjugaison de vis_2). --> Il faut continuer les investigations. *Avant la livraison* On peut raisonnablement penser à une livraison la première quinzaine de juin. Pour cela, d'ici fin mai, il faut une lecture simultanée, et retour aux auteurs des remarques, de la même version des documents "Users manual" et "tutorial" par les membres du groupe. A Martin et Armando d'avertir le groupe quand cela est possible (la dernière semaine de mai). *Après la livraison* La remontée de bug, et/ou de question se fera via le User Support du JMMC (Hervé Beust) qui dans un premier temps transmettra le pb rencontré au groupe Model Fitting qui s'occupera de répondre. A voir à l'usage si un tel mode de fonctionnement est viable. La composition du groupe reste inchangée : chacun a souhaité rester. Quant à l'ouvrir à d'autres : le pb est de trouver des personnes susceptibles de pouvoir rentrer dans le code LITpro, et de suffisamment bien le connaître pour répondre aux questions à son sujet mais aussi pour corriger des bugs... Il ne s'agit plus de trouver des beta-testeurs. Pour l'instant, pas de personne(s) identifiée(s). Début 2010, il pourrait y avoir Jean-Baptiste LeBouquin recruté au LAOG avec une tâche de service JMMC. </verbatim> ---+ 10 Mars 2009 <verbatim> Minutes de la téléconférence du mardi 10 mars 2009 -14h/15h Participants : Guillaume, Sylvain, Gilles, Armando, Olivier, Michel, Isabelle Ordre du jour de la réunion : - User manual donner des réponses aux remarques et questions de Martin (mail du 03.03) - Tutorial : choix de l'exemple 2 : à bâtir - Journées JMMC : rappel de ce qui doit être présenté (talks + séances de travaux pratiques) Prochaine réunion : non programmée. à fixer après les journées JMMC *************************************************************** *User Manual* Le mode contextuel est en cours (i.e; implantation de boutons dans le GUI qui, une fois cliqués, ouvrent le User Manual, à l'endroit adéquat) (action Matin et Guillaume). Paragraphe "Repeat and compare between models" : OK Mettre à jour des noms de paramètres de la Figure 1 (action Martin) Avoir une version "qui tourne" le 2 avril. /remarques de Martin: - Lorsqu'on veut combiner plusieurs modèles, la valeur de flux_weight est à 0 par défaut pour tous les modèles sauf le premier. La mettre à 1. (action Guillaume) - pour l'instant, on ne peut pas traiter simultanément des fichiers différents d'une même TARGET contenant le même INSNAME. Il faut y remédier, de manière à pouvoir traiter le cas polychromatique (une longueur d'onde par fichier et peu de longueurs d'onde) sans attendre l'approche vectorielle. De même, il faut que LITpro permette plusieurs noms différents d'une même TARGET. (action Isa & Michel) - besoin de différenciation des fits successifs (par un nombre ou une lettre, par ex Result_Fit_A, Result_Fit_B...) - rappel des noms et numéros des modèles utilisés pour chaque rapport de résultats, sans quoi ces informations se perdent et si l'on fait plusieurs essais de fit en rajoutant ou en enlevant des modèles, on s'embrouille vite. - de même différenciation et meilleure classification des plots (pour rappel (cf CR précédent), les seuls plots disponibles in fine seront ceux créés via le GUI et TopCat (pas ceux de LITpro)). Accord sur ces 3 remarques de Martin mais il est décidé de les "mettre en attente" : il faut en effet figer une version du GUI, de manière à consolider ce qui existe et préparer les journées, i.e. une livraison à un public certes averti mais qui doit pouvoir découvrir qque chose perfectible mais qui marche. *Tutorial* exemple 1: un fichier d'Arcturus de S.Lacour fitté par un disque uniforme. Manque un paragraphe explicatif sur la normalisation (explications données ds le papier de Goutelas). Ce parag. devra d'ailleurs exister pour chaque exemple du Tutorial. Si la normalisation est ON, il est normal de converger sur flux_weight=1, par contre, l'erreur devrait être 0. (voir si l'on peut abaisser cette erreur, anormalement élevée, mais en attendant, il faut expliquer que cette erreur n'a pas de réelle signification). exemple 2: un fichier de Teta Ori de S.Kraus fitté par une binaire. Même si les journées du JMMC se passeront en petit comité, il est décidé d'avancer au mieux sur ce fit avant les TD du 3 avril. à ce jour, Armando et Olivier ont choisi le fichier : 2007-12-03.A0-D0-H0.ID37509273.EXP0.026.OBJECT-T1ORIC-A.SEL20.oifits mais ce dernier contient des données non calibrées. Olivier va générer, à partir de deux fichiers oifits (SCI, CAL) un oifits calibré. *Journées JMMC* seront présents : Guillaume, Sylvain, Gilles, Armado, Martin, Olivier et Michel. pour les presentations du jeudi: intro et pespectives de LITpro (Michel); entre les 2 : présentation du GUI par Martin, Armando et Guillaume (à vous 3 de vous entendre avant, la veille par ex?); le film d'animation sur le fit d'Arcturus par un disque uniforme, film qui fera partie de la doc, n'a pas beoin d'être réalisé pour ces journées : les étapes du fit via le GUI seront conduites "manuellement". </verbatim> ---+ 5 Février 2009 <verbatim> Minutes de la téléconférence du jeudi 5 février 2009 -14h/15h15 Participants : Guillaume, Sylvain, Gilles, Martin, Armando, Olivier, Denis Michel, Isabelle Ordre du jour de la réunion : GUI et documentation : point et actions Prépa des journées JMMC -3 et 4 avril 09- Prochaine réunion téléphonique : semaine du 9 au 13 mars (date fixée via Doodle la semaine prochaine). *************************************************************** *GUI* Chacun ayant lancé le GUI sur son ordinateur, les commentaires débouchant sur des actions sont les suivants : - permettre à l'utilisateur d'éditer son fichier oifits, à l'aide par ex. de fv (fitsView). Actuellement TopCat ne permet que de le visualiser. - ameliorer la visu des données (afin par ex. de permettre un changement d'echelle) --> on garde les plots créés via le GUI (pas ceux de LITpro) et TopCat est configuré pour simplifier la procédure pour le changement des paramètres de plot par l'utilisateur. --> compléter la liste des plots possibles (par ex. plot radial continu du modèle - lp_plot_radial_model) - sauvegarder les plots / exporter l'information : en plus des formats png et pdf, proposer un format ascii que l'utilisateur pourra reprendre avec son outil de plot favori (idl, yorick, etc). La sortie sous le format oifits a été discutée une nouvelle fois. Remplacer les données par les valeurs fittées est une idée séduisante au premier abord. Mais il est moins simple d'utiliser ce format pour retourner les valeurs du modèle sur d'autres points que ceux mesurés. Rester contraint au format OIdata peut se révéler bloquant dans l'avenir. - déplacer "Result" dans l'arborescence : Result sera une branche de Settings de même niveau que "Files" et "Targets" - créer une arborescence dans les plots, une branche de plots étant associée à un fit - remplacer la terminologie "Dock/Undock" non immédiate --> "Detach/ Attach" ?... - améliorer l'ergonomie des plots de chi2 mettre comme valeurs min et max les bornes du paramètre, si elles existent, - signaler à l'utilisateur que le calcul demandé (qui peut être long) est en cours. Non abordé pdt la réunion : rajouter la possibilité d'arrêter le traitement si jugé trop long - résoudre la gestion des remontées d'erreurs de LITpro via le GUI, liée à la compréhension par le GUI du format des messages d'erreur Yorick. - faire apparaître la définition du résidu sur les légendes des plots. *Documentation* - Users Manual (Martin) intégrer les boutons d'aide contextuelle du GUI qui seront mis à tout endroit nécessaire. L'objectif est de rendre cette documentation opérationnelle d'ici début mars. - Tutorial (Armando) insertion d'un deuxième exemple: une binaire, un exemple impliquant la combinaison de 2 fonctions modèles. --> recherche de données. idée : celles (ou une partie de celles) de S. Kraus sur Theta 1 Orionis (contact et récupération: Olivier) - réalisation de l'animation (Sylvain et Guillaume) associée à l'exemple 1 du Tutorial *Prépa journée du 2 avril* les présents seront : Armando, Olivier, Martin (peut-être), Isabelle ou Michel, Guillaume et Sylvain Proposition : - intro (I ou M) 10mn - présentation du GUI 30mn . en temps réel, démo. étape par étape sur un exemple (A et M si là) . avec compléments d'info (G) - potentialités de LITpro (I ou M) 10mn durées indicatives -40mn interactions- Faire le point est jugé nécessaire 15 jours avant cette journée qui correspond aussi à la livraison du soft : d'où prochaine réunion entre le 9 et le 13 mars. Cette réunion devrait être courte (<= 1 heure). </verbatim> ---+ 8 Decembre 2008 <verbatim> Minutes de la téléconférence du lundi 8 décembre 2008 -14h/15h50- Participants : Guillaume, Sylvain, Gilles, Martin, Armando, Olivier Michel, Isabelle Ordre du jour de la réunion : GUI et documentation : point et actions Prochaine réunion téléphonique début février (date fixée via Doodle début janvier). *************************************************************** Remarques et questions, chacun ayant lancé le GUI sur son ordinateur et suivant les indications de la version actuelle de JMMC_MAN_2300_0001 (user manual). Fichier de données pris pour tester : alphaboo.2006May14.B.1.65mu.oifits Ce fichier oifits n'a pas de OI-ARRAY; LITpro le tolère; le validateur du JMMC l'indique comme warning. Pour ne pas dérouter l'utilisateur, il faut avertir ce dernier que ce n'est pas grave, ni limitant pour la suite, excepté qu'il faut dans ce cas invalider le "Show interferometer sketch", ou alors (réflexion a posteriori) le laisser validé mais afficher un message indiquant que l'absence de OI-ARRAY dans le fichier empêche le plot. --> actions : -définir une stratégie pour de tels fichiers (nombreux...) non rigoureusement de la norme OIFits. Filtrer les messages du validateur ? - vérifier que les fichiers de la zone partagée passent le validateur Fonctions modèles : - description (accessible une fois le modèle cliqué) Actuellement, la description affichée est exactement ce qui est affiché par la fonction help lorsque LITpro est utilisé en ligne de commande. Ce texte ne semble pas correspondre à ce que l'on pourrait attendre via une interface graphique. En particulier, le texte pourrait être enrichi d'une figure du modèle lui-même avec les paramètres. Cette documentation supplémentaire, où doit-elle être gérée ? par le GUI, au niveau du wrapper, ou dans LITpro ? La solution qui semble émerger est la dernière, i.e. que cette documentation (un texte court associé à chaque fonction modèle, dans un format à préciser et pouvant comporter des figures et des équations), soit maintenue dans l'arborescence de LITpro. Le nom des fichiers correspondants pourraient être passés au GUI en utilisant le même mécanisme actuellement utilisé pour les noms des fonctions, les paramètres, leurs unités, etc. --> actions : - décider si le mécanisme proposé est adéquat. - déterminer le format de cette documentation (SVG pour les figures ?). - Le nom des modèles peut être simplifié : par ex., dans le menu, Model[disk:disk] peut devenir uniquement "disk" et dans la liste des fonctions, Model[disk:disk1] peut devenir "disk1" - l'utilisateur doit être amené à choisir les caractéristiques initiales des paramètres du modèle (valeur, bornes, scale, libre ou fixe). Néanmoins, il est décidé que le GUI mette par défaut: - la "value" initiale de flux_weight à 1; - la "HasFixedValue" de x, y, ON sur la première fonction sélectionnée. Remarques générales sur la documentation : - sur la partie 1 : à compléter avec les éléments du papier SPIE (Olivier) - sur la partie 2 (User manual) : à actualiser avec les nouvelles fonctions modèles et les plots (Martin) --> action : répondre à la question : des pointeurs sont-ils possibles das LateX ? - sur la partie 3 (tutorial) : 2 à 3 exemples à commenter (Armando) et film d'animation sur le fit d'Arcturus par un disque (Guillaume & Sylvain) juste avant la livraison. Celle-ci peut être fixée au début du printemps 2009. Si date nécessaire, pourquoi pas la journée JMMC du 3 avril. D'ici là, priorité certes est donnée au développement du GUI et à la documentation associée, mais aussi aux tests des fonctions modèles avec sans doute de nouvelles données partagées. La remontée des bugs rencontrés doit se faire par l'envoi à Guillaume du setting concerné et copie du message d'erreur. </verbatim> ---+ 20 Octobre 2008 <verbatim> Minutes de la téléconférence du lundi 20 octobre 2008 -14h/15h15 - Participants : Guillaume, Gilles, Evelyne, Olivier, Martin, Armando, Michel, Isabelle Excusés : Sylvain, Denis Ordre du jour de la réunion : I- Tour de table II- Actions à court terme sur le GUI et LITpro Prochaine réunion téléphonique début décembre (date fixée via Doodle au plus tôt). *************************************************************** I- Tour de table o Olivier avec interactions Guillaume et Gilles à partir des templates fournis par JMMC (les mêmes qui servent à la doc. de Search Cal), Olivier se charge, avec l'aide de Martin et d'Armando, de l'écriture de la doc du GUI. Celle-ci se composerait de 3 parties : 1- une générale, explicative, sur ce qu'est LITpro (avec reprise des parties explicatives des articles existants, celui de Goutelas 2006 et SPIE 2008) --> fourniture à Olivier des fichiers latex. 2- un tutorial, basé sur des exemples, enrichissable au cours du temps (démarrer avec celui de Goutelas, encore à jour jusqu'au sniffer -la fonction a changé depuis-) 3- un "user manual" pour utiliser le GUI, qui comprendra une vidéo du type de celle montrée par Guillaume et Sylvain en juin dernier, sur un exemple précis. Il est décidé de prendre comme exemple un exemple simple, celui du disque uniforme sur des vraies données. --> recherche de ces données (AMBER (Gilles), Arcturus (Isa : redemander à S. Lacour)) o Evelyne : a commencé à plonger dans le code. RAS. L'objectif est la recherche du minimum global. o Martin : Il a obtenu un poste d'IR à Fizeau-Nice, qui démarre le 1er décembre. Il devrait pouvoir débloquer du temps pour continuer une activité au sein du groupe. En attendant, il peut : - finaliser la mise au propre de l'écriture en yorick de plusieurs modèles chromatiques simples (modèles d'étoiles en rotation/expansion avec ligne d'emission/absorption) - s'occuper de la documentation du GUI (principalement la partie 3) o Armando : comme Olivier, peu de disponibilité en novembre, mais peut contribuer à la doc-GUI avant. o Isa et Michel : Depuis la dernière réunion du 16 juin, amélioration des fonctions de plot de LITpro et rédaction du papier SPIE. II- Actions à court terme sur le GUI et LITpro GUI : - ajouter les plots existants dans LITpro et non encore sur le GUI, comme le chi2, la sniffer_map. - intégrer le passage au validateur oifits : l'utilisateur doit vérifier si ses données sont au format OIFits. C'est un test "informatif" qui lui indiquera s'il y a des écarts au format. Si c'est le cas, c'est à lui de se débrouiller, pour faire disparaître ces écarts. Le passage du fichier de données à travers le validateur doit se faire une seule fois (si le fichier est de nouveau appelé, ne pas refaire le test --> mise d'un flag (c'est possible)) GUI/LITpro homogénéiser les configs : s'assurer que le GUI travaille avec la distrib. LITpro et la version Yorick compatibles avec celles de Lyon. pour aider à cela : création d'un compte cral sur une machine du JMMC à Grenoble où l'on pourra se connecter pour faire des essais. LITpro : - consolidation des fonctions modèles de base (assombrissement centre-bord) et changement des paramètres de ces fonctions comme décidé antérieurement. - écriture de la fonction show_data - Rque : LITpro est assez tolérant quant au format de données : si celles-ci ne sont pas parfaitement OIFits, elles peuvent néanmoins être lues sans vraiment informer l'utilisateur des problèmes contournés. Si nécessaire, LITpro pourrait donc aider à tester le contenu des données OIFits en faisant remonter les pbs (par ex. visibilité supérieure à 1). </verbatim> ---+ 16 Juin 2008 <verbatim> Minutes de la téléconférence du lundi 16 juin 2008 -14h/16h - Participants : Martin, Olivier, Armando, Guillaume, Gilles, Evelyne, Isabelle, Michel Ordre du jour de la réunion : 1- tour de table 2- actions faites depuis la dernière réunion sur le GUI et LITpro 3- actions à court terme sur le GUI et LITpro 4- réflexions/discussions sur les pages Web Prochaine réunion téléphonique fin septembre (date fixée via Doodle début septembre). *************************************************************** 1- Tour de table o Martin : appelé à intervenir sur le logiciel au niveau notamment des fits chromatiques (cf synthèse de Martin archivée sur la liste de diffusion en mai 08) Jusqu'à présent : - prise de contact avec le code - écriture de plusieurs modèles chromatiques simples (par ex.fond continu + raie gaussienne) et simulations numeriques d'étoiles en rotation avec émission, avec ou sans vitesse de fuite, et étoiles en expansion - travail sur l'estimation des visibilités différentielles - écriture d'une routine pour extraire les SED des fichiers OIdata mais la dernière version de amdlib fournit celle-ci. o Isa & Michel : fit de données interféro. et SED avec fonction chromatique - données = RLeo obtenues sur IOTA sur 4 bandes spectrales en K, extraites du papier Perrin et al, A&A2004, 426, 279; SED = 4 mesures en HJKL de Whitelock; - modèle chromatique = équation dans le papier, l'étoile est un disque entouré d'une couche moléculaire; - fichier modèle = constitué de 5 targets ("TG"), la dernière étant la SED et les 4 premières étant associées aux 4 canaux spectraux des données interfero. Partage de paramètres entre eux, comme les températures et la dimension angulaire de l'étoile et de la couche mais paramètre chromatique (l'épaisseur optique) pour chacune des 4 longueurs d'onde. - résultat = le fit des visibilités est similaire à celui du papier, celui de la SED est meilleur, mais surtout : le fit simultané SED et visibilités est relativement facile (converge vers la même solution sur une grande plage de jeux de paramètres initiaux) alors que sans SED, il faut fixer l'une des températures. (plus de détails dans publi SPIE à venir) Ce travail a permis également d'amorcer la réflexion sur la gestion de paramètres vectoriels. o Armando : essai de fit via le GUI d'un fichier AMBER sur Canopus avec une limb-darkening function. Plantage non reproduit à Lyon. --> pour deboguer, se connecter sur une machine où le bug a lieu et l'étudier. Il est probable que le bug soit lié à la précision machine. o Guillaume : cf point 2 2- actions faites depuis la dernière réunion sur le GUI et LITpro o Guillaume : - correction de bugs remontés par Armando - affichage des resultats plus rapide - uniformisation au sein des GUI du JMMC/LAOG au niveau de JAVA (travail d'un stagiaire) - validateur de données OIFits : peu de monde l'a encore testé. o Isa & Michel : - flags OI-data mis en place et testés - nouveaux moyens de visualisation * show_chi2 : plus besoin de fitter pour avoir le chi2 (fit à la main) * show_normalize. alarme si résidu de normalisation non nul ("trop grand") * plot sed * plot continu des modèles, pas seulement sur les coordonnées des données (radial_model-choix des angles de coupe-, sed_model) - améliorations de routines de diagnostics (plots, visu, etc) * localisation du min et max dans chi2_slice et sniffer_map * triage des paramètres pour affichage (utile qd grand nombre de paramètres) - manipulation des paramètres avec globing patterns (*) (grand nombre de paramètres) - amélioration interne du code : * fonctions de servive --> allègement du code - lecture des données non-oidata * expérimentation sur fichiers ascii * à noter : la couche de lecture oi-data est en train d'être réécrite pour MIRA, puis sera synchronisée avec LITpro. La re-synchronisation avec MIRA est utile (elle permettra notamment l'écriture de fichiers OIfits (en vue de données simulées) et l'importation de fichiers acscii pourrait être implantée après. 3- actions à court terme sur le GUI et LITpro (court terme = d'ici la prochaine réunion) - GUI : plot des données sans le modèle besoin d'une documentation : - premier niveau : o doc écrite (Olivier, Armando, Martin) pour guider l'utilisateur à travers le GUI o démo. virtuelle (Guillaume, Sylvain) - montrée après la réunion - solution attrayante ! - second niveau : sur les fonctions mêmes du logiciel apelées par le GUI récupérer la doc de LITpro; remonter les help des fonctions mais est-ce suffisant ? et continuer de tester à l'aide de nouvelles données et fits - LITpro * distrib avec les fonctions nouvelles écrites récemment * changement de la nomenclature des paramètres dans bibliothèque de fonctions modèles comme décidé en avril * consolidation des fonctions d'assombrissement 4- réflexions/discussions sur les pages Web - la page http://www.jmmc.fr/model_fitting_page.htm a été créée, pour l'instant accessible par les membres du groupe qui seuls la connaissent, sera ensuite une rubrique du site du JMMC. elle est à compléter. De même, le descriptif du groupe de travail est à actualiser sur le site du JMMC. - page twiki : à maintenir et faire vivre; d'elle partent les accès aux autres pages du groupe - page des données privées (non encore publiées) http://apps.jmmc.fr/oidataPrivate/ il est décidé unanimement d'y accéder via un mot de passe unique Pour conclure ce CR, on peut garder en tête la question de Gilles : "qu'est-ce qui existe ailleurs, en matière de fit de données hétérogènes (et polychromatiques) ?" Des réponses seront peut-être données lors de la conférence SPIE la semaine prochaine. </verbatim> ---+03 Avril 2008 <verbatim> Minutes brèves de la téléconférence du jeudi 3 avril 2008 -10h/12h40 - Participants : Olivier,Denis, Armando, Martin, Romain, Guillaume, Gilles, Isabelle, Michel Ordre du jour de la réunion : 1- point sur le GUI (accès VNC sur poste de Guillaume) 2- point sur LITpro et sur les données tests via les pages wiki 3- validateur oi-fits développé par Guillaume : status 4- réflexion à avoir sur notre façon de communiquer ? + Mise en place d'une liste de diffusion : est-il temps ou est-ce prématuré ? *************************************************************** 1.Démonstration du GUI (avec Olivier aux manettes) - effort sur les plots effectué. A faire : o plotter separement les T3, VIS2, VISamp... o pouvoir visualiser les données avant de leur associer un modèle A noter (demande de Guilaume): dorénavant, veiller à utiliser la version STABLE de GUI uniquement (et non plus la version BETA sur laquelle travaille Guillaume). Les basculements seront plus fréquents entre les 2 versions. 2.Discussions/réflexions à partir des données testées. Point sur LITpro - sur RY Sgr : les erreurs étaient dues à une malformation des fichiers (ucoord=vcoord=0 et mauvaises unités spectrales). Après corrections, l'ajustement montre que les données (MIDI) sont fortement corrélées (chi2 reduit << 1). Rappel : LITpro est conçu pour fitter des données de format OIFits, i.e. des visibilités calibrées (i.e. normalisée à 1 à l'origine). Une hypothèse de base est l'indépendance des mesures. Plusieurs sources de corrélation des mesures existent sur les instruments, ce qui contredit l'hypothèse de base. Par ordre d'importance: - Calibration photométrique (normalisation à l'origine) - sur-échantillonnage en fonction de la longueur d'onde A faire : o permettre de travailler sur les données brutes, i.e. avant normalisation, pour fitter objet et calibrateur(s) en parallèle. Il faut définir comment distinguer les données brutes des données calibrés OIFits. Possibilités (rien n'a encore été décidé): - nouvelles tables dans les OIFits ? (e.g OI_VIS --> OI_VIS_RAW) - Flag dans les fichiers OIfits ? Avant de décider, avoir une vision claire de ce que "subissent" les mesures de MIDI jusquà ce qu'elles deviennent des fichiers OIData : écrire si possible sous forme analytique, lister erreurs et biais (action Olivier) o Olivier va corriger les autres fichiers de données de RY Sgr (tabvis***) et faire un fit global. Les variations photométriques entre les divers calibrateurs devraient permettre d'obtenir une value du chi2 plus raisonnable. - sur Achernar explication du paramètre weight et de l'option "Normalize" dans les settings (à implanter dans la doc). A faire : o option "normalisation "on" ou "off" du modèle à remonter dans le GUI o finaliser le choix de la dénomination des paramètres des fonctions géométriques de base : avant le 9 avril 2008 o créer une page de données partagées uniquement au sein du groupe (accès avec password). Y mettre les données non encore publiques, notamment celles permettant de tester le fit multi-chromatique o remonter les outils de diagnostic (sniffer et chi2-slice) dans le GUI Récapitulatif des améliorations de LITpro depuis la dernière fois: - Suite aux tests d'Olivier, des bornes par défaut sont maintenant définies dans les fonctions de base et remontées par l'interface. - Suite aux tests d'Olivier avec un fichier OIData mal formé, durcissement du calcul des matrices de covariance. - Le problème du calcul des fréquences spatiales détecté par Armando (erreur sur la longueur d'onde lorsqu'il y a plusieurs tables WAVELENGTH) a été corrigé. - Plusieurs corrections dans le fitter, en particulier sur le respect strict des bornes. - Les fonctions de base géométriques sont maintenant toutes fiabilisées. Il reste à effectuer la même opération sur les fonctions d'assombrissement centre-bord. - Amélioration de l'outil pour produire les distributions. Une nouvelle distribution sera faite après la fiabilisation des fonctions d'assombrissement centre-bord. 3. Le validateur de données OIFits a fait ses premiers pas, avec succès. Il sera accessible prochainement via une page web. On lui donne le fichier; il nous renvoie les champs existants et ceux qui devraient y être mais qui n'y sont pas. 4. Pas de consensus sur "uniquement page Twiki" ni sur "la mise en place d'une liste de diffusion". Donc compromis avec l'utilisation du mail incluant commentaires, explications avec pointage si besoin sur la page Twiki. et sur celle-ci, trace des echanges, actions à faire, etc. On refera le point la prochaine fois. besoin également d'un lieu dédié au debogage (où sont répertoriés les bugs rencontrés et leur status) mais pas de conclusion nette à ce sujet. Prochaine réunion téléphonique entre la mi-mai et fin mai (date fixée via Doodle fin avril). A noter : venue de Martin à Lyon du 28 au 30 avril. </verbatim> ---+ 19 Fevrier 2008 <verbatim> Minutes brèves de la téléconférence du mardi 19 février 2008 -10h/11h40 - Participants : Olivier, Armando, Guillaume, Sylvain, Isabelle, Michel Objectifs de la réunion : 1- éclaircir les actions possibles d'Armando et Olivier 2- découvrir l'interface graphique développée par Guillaume 3- décider comment d'organiser au mieux 1. Armando et Olivier ont des données AMBER, MIDI d'objets pas trop compliqués + des calibrateurs : ces données peuvent servir : - à s'exercer sur LITpro - via l'interface - à alimenter in fine LITpro avec des exemples (du type Obj1 de Goutelas) pour aider aux tests et à l'initiation au logiciel de l'utilisateur lambda. discussion sur le format des données : peu de ces données sont sous format OIFits, mais simplement ASCII. Double consensus sur : - le fait que le Model Fitting ne travaille qu'avec le format standard des données, i.e. OIFits; à l'utilisateur de transformer si besoin le format de ses données - le besoin d'un "validateur - intégrateur" de données OIFits. l'idéal serait de produire des convertisseurs des anciennes données de MIDI ou d'AMBER vers le format OIFits, (opération plutôt manuelle avec la solution sous IDL de J. Monnier) action en projet au sein du groupe de Guillaume, pour la validation (en discussion pour l'intégration) 2. Démo. de l'interface graphique via VNC par Guillaume http://jmmc.fr/~mella/LITpro - "révision" de certaines caractéristiques de LITpro (comme le partage d'un paramètre par plusieurs briques, etc). - présentation de qques potentialités de topcat 3. Actions pour organiser la collaboration entre les membres du mini-groupe : - Mise en place d'une page Twiki, lieu d'échanges et de visualisation des avancées, questions et réponses du groupe possibilité d'activer le service de Notification (on reçoit un mail lorsque la page a été modifiée). - Mise en commun de données : sur une page web gérée par Guillaume. Au départ : simplement, puis de manière + sophistiquée plus tard (par ex., avec accès protégé pour certaines données) - RdV ~ mensuels par téléconf (1 heure max) pour faire le point : prochaine téléconf. entre le 17 et le 28 mars (TBF par mail). - réactivation d'une liste de diffusion dans un mois environ, une fois que les actions du mini-groupe seront bien lancées. (copie de ces minutes à Denis et Romain - qui se réunissent vendredi avec Armando et Olivier qui leur montreront l'interface graphique );) </verbatim>
Attachments
Attachments
Topic attachments
I
Attachment
History
Action
Size
Date
Who
Comment
txt
minutes-100309.txt
r1
manage
3.6 K
2009-03-19 - 09:39
IsaTallonBosc
pdf
reunion-190612.pdf
r1
manage
281.0 K
2012-06-22 - 08:14
IsaTallonBosc
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r29
|
r27
<
r26
<
r25
<
r24
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r25 - 2013-01-29
-
IsaTallonBosc
Home
Site map
Jmmc web
Faq web
ProspectiveHRA2014 web
Software web
VltiSchool2010 web
VltiSchool2013 web
VltiSchool2015 web
VltiSchool2018 web
Main web
Sandbox web
DeuxiemePage web
TWiki web
Software Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
P
View
Raw View
Print version
Find backlinks
History
More topic actions
Edit
Raw edit
Attach file or image
Edit topic preference settings
Set new parent
More topic actions
Account
Log In
Register User
Edit
Attach
Copyright © 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