JmmcModelFittingCRReunionsDuGroupe < Jmmc/Software

Tags: view all tags
Cette page liste les minutes également diffusées par mail au sein du groupe.
%TOC%

---+ du 2 au 5 février 2016
<verbatim>
*Participants* : Guillaume, Michel et Isa au CRAL
*séance de travail / fonctions utilisateur (ou user models) * (suite)

- les travaux de l'an dernier ont été fusionnés dans la version de production
  pour faciliter le développement de la version avec modèles utilisateur,
  conjointement aux travaux sur les fitters et aux corrections de la version de
  production.

- Design des nouveaux fichiers de settings qui incorporent les opérateurs.

- Simplifications des règles de fonctionnement et d'utilisation des fonctions
  de base et des opérateurs.

- Début de rédaction d'un document décrivant le design de l'implémentation des
  modèles utilisateur.

- Solution trouvée pour calculer les rapports de flux entre composantes d'un
  modèle, en fonction de la longueur d'onde. Devrait être implémenté en même
  temps sur le moteur développé pour les modèles utilisateur.

Une journée est bloquée, celle du 22 mars, pour faire le point. 
Se contacter une semaine avant pour voir si téléconf. suffit.

</verbatim>

---+ du 6 au 8 janvier 2016
<verbatim>
*Participants* : Michel et Hervé à l'IPAG 
*séance de travail / fit génétique dans LITpro*

L'objectif était de faire fonctionner le fitter génétique genfit pour qu'Hervé
puisse être autonome pour tester l'efficacité et améliorer ce fitter.

L'analyse de la première version de genfit avait montré la nécessité de revoir
la nouvelle interface des fitters dans LITpro. Cette séance de travail
nécessitait le test et la mise au point de cette nouvelle interface.

L'objectif a été entièrement rempli. Notamment, les étapes suivantes ont été
effectuées lors de cette séance de travail :

- Installation de yorick, LITpro, et d'un environnement de travail sur la
  machine de Hervé.

- Validation de la nouvelle interface des fitters dans LITpro. Cette interface
  est aussi l'interface opérationnelle avec trfit, le fitter par défaut.

- Validation du fonctionnement de genfit dans le cadre de la nouvelle interface
  avec retour du nombre d'évaluation du modèle, pour évaluer les performances.
  Pour rappel, genfit peut lancer un nombre donné d'itérations de trfit à
  partir de positions de départ déterminées par l'algorithme génétique.

- Premiers tests des performances de genfit sur les données
  arcturus_1.52mu.oifits (utilisées dans le demo setting 1 de la page web de LITpro ou dans le TD des écoles VLTI). Pour
  ce premier test, il s'agit de trouver le diamètre de l'étoile dans un
  problème à une seule dimension présentant quelques minimums locaux.

  o Le minimum global est systématiquement atteint.

  o Les tests montrent un nombre d'évaluations du modèle très variable et assez
    aléatoire qui semble dépendre de l'évolution imprévisible des générations.

  o Ce nombre semble dépendre assez fortement du nombre d'itérations et des
    critères de convergence donnés à trfit.

- Prochaines étapes :

  1/ Tester et améliorer le comportement de genfit.

  2/ Mettre en place une procédure automatique d'évaluation des fitters pour
     comparer leurs performances sur des données variées.

  3/ Mettre à jour la documentation de l'interface des fitters dans LITpro.

  4/ Implanter de nouveaux fitters de recherche de minimums locaux (nlfit,
     nelder-mead) et de nouveaux fitters globaux (recuit simulé en haut de la
     liste).

- Prochaine séance de travail à fixer en fonction de l'avancement des étapes
1/ et 2/. 

</verbatim>


---+ du 7 au  9 juillet 2015
<verbatim>
*Participants* : Guillaume, Michel et Isa
à l'obs à St-Genis. 
*séance de travail / fonctions utilisateur * (suite)
</verbatim>

---+ du 5 au  8 mai 2015
<verbatim>
*Participants* : Guillaume, Michel et Isa
à l'obs à St-Genis. 
*séance de travail / fonctions utilisateur *
</verbatim>

---+ 10 Janvier 2014
<verbatim>
*Participants* : Hervé, Gilles, Guillaume, Laurent, Michel et Isa
de 14h à 15h30 env. par téléconf. le 10 janvier.

La réunion a pour seul objet le point sur de nouveaux fitters pour
LITpro, et plus précisément sur le travail entrepris par Hervé pour
implanter un algo génétique dans LITpro. 

Elle fut suivie par une réunion de travail entre Hervé et Michel à
l'IPAG le 16 janvier après-midi.
_____________________________________________________________________
*1. Au préalable, qques remarques sur d'autres algorithmes
d'ajustement essayés par Michel*
Essais réalisés sans les implanter dans LITpro.
- algo Nelder-Mead avec bornes (méthode du simplex), qui ne nécessite
pas le calcul des différences finies. Algo qui demande plus
d'évaluations du modèle. Contrairement à l'étape du calcul des
différences finies, tous les paramètres sont changés à chaque appel du
modèle, ce qui nécessite de ré-évaluer tout le modèle.

- nouvelle version algo Levenberg-Marquardt, "plus propre", mais sans
les bornes. La convergence est plus lente, sans doute à cause d'un bug
dans la mise à jour de la région de confiance. (à noter: la vitesse de
convergence dépend du nombre d'évaluations du modèle; c'est lui qui
importe plus que le nombre d'itérations)

Ces essais d'autres fitters et l'implantation dans lITpro de fitters
autres que LM modifié avec bornes et régions de confiance, sont motivés
par la recherche du minimum global qui passe par la recherche rapide
des minima locaux. Il y a un équilibre à trouver entre le nombre de
solutions de départ et le nombre d'évaluations du modèle. 

Pour la recherche des minima locaux, trfit est toujours le plus
efficace. Réflexion en cours pour effectuer un calcul partiel du modèle
lors du calcul des différences finies où un seul paramètre à la fois est
changé. Le gain en vitesse pourrait être très significatif, en
particulier pour les modèles physiques.

_____________________________________________________________________
*2- Algo génétique d'Hervé

L'intérêt d'un algo génétique est qu'il garantit un meilleur brassage
de solutions pour aboutir, à la fin, à ce que tous les individus
soient égaux. La difficulté est de savoir quand on s'arrête. Le choix
de Hervé est de s'arrêter quand les solutions ont des chi2 identiques.

Hervé a bâti son code en se référant à ce qui avait été fait sur le
fitter implanté dans LITpro (trfit). Il a décrit précisément l'état
d'avancement dans un mail (mis en attaché, de même que le mail d'Hervé
après la réunion à Grenoble avec Michel). 
Il a écrit également la fonction lpf_genfit_show pour visualiser la
meilleure solution à chaque étape.

On peut lister les points suivants discutés lors de la première
réunion et repris lors de la seconde :

- ne pas considérer trfit comme un exemple canonique car il a été
  programmé avant que l'interface générique pour les fitters ait été
  imaginée, et avec un cahier des charges bien plus lourd, aujourd'hui
  caduque.
- nécessité de faire remonter au niveau de l'interface quelques
  fonctionnalités (récupération vmin, vmax et scale de tous les
  paramètres)
- il n'est pas nécessaire de clôner world dans un world temporaire.

Pour tester l'algo., les données ne manquent pas. Pourront être prises
dans un premier temps celles des exemples du tutorial.

La suite des actions sera visible sur la liste de diffusion.  Pas de
réunion programmée pour l'instant mais des interactions par telephone
ou mail. Quand tout sera testé et opérationnel, un point avec
Guillaume sera nécessaire pour voir la répercussion sur le GUI.

</verbatim>

   * [[%ATTACHURL%/mail_Herve_100114.txt][mail_Herve_100114.txt]]: mail_Herve_100114.txt
   * [[%ATTACHURL%/mail_Herve_220114.txt][mail_Herve_220114.txt]]: mail_Herve_220114.txt



---+ 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
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
txt	mail_Herve_100114.txt	r1	manage	7.3 K	2014-01-28 - 13:38	IsaTallonBosc
txt	mail_Herve_220114.txt	r2 r1	manage	2.7 K	2014-01-28 - 19:51	GuillaumeMella	utf-8 encoded
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
Topic revision: r29 - 2016-02-05 - IsaTallonBosc