Présent
- Hervé M.
- Juhui W.
- Hervé R.

Objectif
Affiner et pointer la feuille de route 2011

Discussion / décisions
- print
difficultés techniques avec print : méthodes, fonctions, généricité ...
solution retenue :
    - écrire des fonctions print sur nos classes (mtklevel, mtkValue, ...) qui fonctionnent avec le mécanisme S3
    - les print des listes de nos objets reste le print "natif" d'une liste
    - dans un second temps nous traiterons ce pb. La solution sera peut-être de créer des classes pour les listes de ces objets.

- feuille de route :
**point 1 : 1 Consolidation du code** (HR)
    - //éclater les méthodes// : bonne idée mais dangereuse => pas prioritaire
    - //choix de nommage// : setName plutôt que setMtkValueName
    - //print et show//: écrire les méthodes et/ou fonctions des classes (ne pas surcharger le print pour liste)

**point 2 : intégration de méthodes** (JW)
    - mise en œuvre de la solution la plus simple à implémenter : encapsuler dans une classe la fonction à intégrer.  Cela permettra un premier usage à partir duquel on étudiera les spécifications à mettre en œuvre pour mettre en place un mécanisme de plugin plus robuste (analyse des fichiers d'un répertoire au moment du chargement de mtk)

**point 3 : échanges plate-formes**
    - pas prioritaire : à traiter après la livraison de la première version mtk (janv 2012)

**point 4 : la doc**
    - gérer les sources des doc sous svn de la forge
    - présenter les documents sous mexico.org :
        - man de référence à valider (construit avec roxygen)
        - guide du développeur : proposition de partir du guide ébauché par HR pour valider ensemble un plan et se repartir la rédaction.
        - vignette (HM V2)
        - tableau xmind (HR)
        - liste des méthodes et lois accessibles avec MTK (HR/Nejdi)
        - checklist pour construire le package
        
 **point 5 : Reprise des calculs**
non prioritaire

**point 6 : Tests**
il faut pouvoir disposer de tests de non régression ainsi que des tests unitaires, HR a commencé de mettre en place des TU sur certaines classes, il faudrait trouver une approche générique.
    
**point 7 : reporting**
Dans un premier temps des méthodes //show/print//, //summary// et report

**propositions/ TODO**
- JW : vérifie le pb qui plante actuellement 2 des 3 démo
- JW : compréhension du mécanisme de visibilité des classes et méthodes (namespace)
- JW : roxygen a évolué en roxygen2, il faut donc vérifier la complète portabilité des fonctions mises en œuvre dans mtk
- HR fait suivre le travail réalisé pour le guide du devlp. (dans l'état)
- HR fait suivre la checkList pour générer un package
- HR fait la page récapitulative de la doc sous mexico.org
- HR publie les tests unitaires réalisés

**proposition d'agenda**
 - HR est chargé de dégrossir la procédure de visio par skype et d'informer le groupe pour continuer les échanges pendant le séjour de HM en GB
 -  dès la procédure connue, le trio fixera le prochain RV

       

La présentation des différentes études de cas encodées en XML selon le schéma expDesign.xsd à soulevé le besoin de mieux spécifier les objectifs de ces schémas : doivent ils contenir tous les facteurs ou simplement ceux qui sont utilisés dans le plan d'expérience ?

On constate que selon que l'utilisateur passe par une plateforme de modélisation/simulation ou non les besoins d'informations sont différents. L'investissement pour créer les outils qui manipuleront ces documents XML est également différent selon que ce soit pour un usage pérenne (plateforme) ou un simple coup (utilisateur direct).

 

Il faut trouver un consensus pour que le document XML contiennent toutes les informations nécessaires à une étude donnée (au plan d'expérience utilisé). Les autres facteurs fixés peuvent ou non apparaître dans le document selon le besoin de l'utilisateur.

 

On retient le principe suivant :

• les données de l'analyse (spécifications du plan d'expérience, de ses facteurs et du workflow) sont décrites dans un document XML, il reste possible pour l'utilisateur d'ajouter des informations concernant des paramètres fixes pour une étude donnée, mais ce n'est pas l'objectif principal.

• Une structure R correspondante est réalisée,

• un parser permet la lecture de l'un vers l'autre dans les 2 sens, Si le workflow est également renseigné dans le XML le parser générera également une structure de ce workflow sous R.

• un package R mexico sera réalisé et permettra de manipuler cette structure R grâce à un ensemble d'utilitaires sous forme de fonctions R.

• La structure sera proche de celle utilisée pour l'EC. On s'appuiera sur les classes définies lors du stage de D.W (08 - Éric/Hervé R.).

 

Les outils collaboratifs

Le groupe confirme l'appui sur la forge de MIA pour partager les codes et mettre en place un mécanisme de proposition de modification des formats XML

 

Répartition des tâches

• Hervé R. met en place le projet sur la forge (avant le 22/07) avec les consignes pour son utilisation et prend en charge la structure R

• Yuhui Wang prend en charge le parser R/XML (dans un premier temps sous R avec le Package RXML)

 

Une nouvelle version du schéma est proposée par Hervé M. avec comme caractéristique majeur un élément « feature » caractérisant les facteurs. L'intérêt de cet élément est de pouvoir intégrer les informations diverses qui caractérisent les facteurs selon leur nature.

Une page sur le site Mexico sera créée pour définir de manière collaborative les caractéristiques de la structure R. Elle permettra de déboucher sur un diagramme de classe.

Un calendrier des échéances et événement est mis en place (voir le calendrier du site).

1 - Ordre du jour

 

Partie Organisationnelle

proposition d'un principe de fonctionnement pour le groupe à débattre

 

Partie Technique

• le point sur le schéma :

• spécification du workflow

• méthodes à implémenter (ce point incluant la discussion commencée par les échanges Nantes/Jouy)

• structures sous R

• point sur les outils de développement collaboratifs et circuit des sources et soumission de modification

2 - Partie Organisationnelle

Objet:
débattre de la proposition d'un principe de fonctionnement consistant en un développement de l'outil piloté par Hervé R., Hervé M. et Juhui

Rappel du message :

Le constat
Incontestablement le groupe, par sa pluralité, permet d'avoir une conception très large des outils que nous souhaitons développer, cela nous donne quasiment l'assurance de fournir une boite à outils qui aura une pleine utilité. Cependant, cette large échelle a un coût : les échanges sont assez espacés, les temps de décisions longs, les avancées modestes, etc ...
Nous pensons que parmi les raisons principales de ces problèmes de fonctionnement, il y a une répartition des tâches insuffisamment explicite, le fait que personne n'est clairement investi de la responsabilité de l'avancement du projet, et le fait que l'implication des partenaires sur différentes plates-formes de modélisation rend plus difficile l'établissement des priorités. Dans un monde où nous serions tous très disponibles, ces difficultés seraient facilement surmontables, mais dans le contexte actuel, elles représentent un frein préjudiciable à tous.
Or nous sommes motivés pour poursuivre ce projet.

Alors, comment fonctionner pour ne pas tomber dans les travers évoqués ci-dessus?
D'abord nous proposons de clarifier le rôle de chacun :
Un bref tout de table en juillet a précisé, s'il en était encore besoin, que les 2 seules personnes qui ont la possibilité de donner du temps pour les aspects techniques tels que le codage sont Juhui et Hervé R.

La personne qui a l'approche la plus complète est Hervé M. (à la fois du point de Stat et outils R (connaissance et  développements, etc.))
Nous proposons donc de construire un noyau actif avec Hervé M. comme chef d'orchestre, Juhui et Hervé R comme acteurs-développeurs. Le reste du groupe interviendra comme "expert" et/ou "commanditaire" au sein d'un comité de pilotage validant les travaux.
En résumé nous souhaitons recentrer le projet sur une équipe INRA à la fois plus légère et plus proche pour plus de rapidité et d'efficacité  dans les développements

Cette proposition ne remet pas en cause l'objectif de développer des outils qui conviennent à chacun, et chacun pourra continuer à exprimer son avis sur le travail, mais elle devrait nous permettre de sortir de la lenteur actuelle qui risque de nous enliser.
 

Discussion :

SM: l'éparpillement géographique est une source de difficultés, mais le fait que le projet ne soit pas financé est aussi un frein à l'investissement personnel. Le groupe doit envisager de répondre à des appels d'offre ANR ou autre pour donner une meilleure assise au développement de la BaO (qui pourrait par exemple être un Work Package). Ne pas perdre en flexibilité dans la construction de la BaO et ne pas se limiter à des modèles INRA.

HM: l'intention est bien de continuer à s'appuyer sur l'ensemble du groupe, avec un rôle de comité de pilotage, et à intégrer les modèles INRA et non INRA.

RF: ok pour que d'autres que lui prennent en charge le développement, envisage son propre rôle plutôt comme testeur. Il faut un programme de gestion du développement et des points relativement fréquents.

ND: Perte d'investissement: le manque d'organisation (référentiel de doc, specs, …) a été préjudiciable. La composition de ce groupe pilote/coordinateur permettra de mieux contrôler l'animation du groupe.

BP: les difficultés actuelles sont liées au manque de communication. Plaide pour que les échanges soient systématiquement ouverts à tout le groupe. C'est une erreur de préocéder autrement.

HM: ne s'engage pas à ce que les échanges entre HR, JHW et HM soient systématiquement ouverts, mais ok pour prendre en compte cette position le mieux possible

Décisions:

- ouverture d'une liste mail pour le groupe

- prochaine réunion physique du groupe programmée le 16/02/10

Tâches identifiées :
 - développement du schéma
 - documentation du schéma avec des exemples sur des cas d'utilisation
 - développement de la boîte à outils 

Partie Technique

 a) le point sur le schéma :

• dernière mise à jour du schéma expDesign.xsd sur la forge

• explication sur l'utilisation des éléments « feature » dans les éléments « factor »

• spécification du workflow

Demande de Clermont: pouvoir décrire les transitions entre les process, ce n'est s pris en charge actuellement

• méthodes à implémenter (ce point incluant la discussion commencée par les échanges Nantes/Jouy), en particulier il faudra réfléchir à la façon de décrire des facteurs dépendants.

• structures sous R
   les classes R doivent refléter la conception du schéma

b) point sur les outils de développement collaboratifs et circuit des sources et soumission de modification

rappel de l'organisation du projet sur la forge MIA (voir les informations sur le site dans la rubrique "outils collaboratifs")

2 arborescences sont utilisées actuellement :

• la gestion des sources à l'aide de SVN

• l'outil de suivi

 

excusés : Stéphanie et Nicolas

ODJ

L'ordre du jour proposé est simple :

• Préciser le diagramme de classes que nous avons conçu

• Point en terme de programmation

• Discussion générale et recueil des avis par rapport à tout cela.

 

Discussion autour du diagramme de classes :

demande de précision sur la classe SamplingInterface,

quelle relation entre Sampler et SamplingInterface ?

• la partie générique sera dans Sampler, et la partie spécifique sera dans SamplingInterface

• rappel : une interface doit être un contrat entre les 2 classes

• « zone » encore en construction qui permet de se répartir les taches

• l'objectif est de conserver le plus de généricité possible pour l'appel des méthodes

• L'idée est de construire une lib R avec ce qui est développé autour des appels aux méthodes. Cela peu apporter une aide a toute personne qui veux faire ce type de dev.

• Chaque interface de processus peut éventuellement présenter des éléments factorisables dans la classe interface.

BP informe de la disponibilité de code Lutin pour tester l'implémentation dans ISIS

 

Comment sont utilisés les facteurs dans les processus ?

Par des méthodes non encore visualisées explicitement sur diagramme.

 

Existe t il une méthode pour que les processus puissent identifier l'ensemble des facteurs disponibles ?

Pour l'instant ce n'est pas (encore) géré mais pourrait apparaître, selon les besoins. Il faut identifier à quel moment ( à quel endroit) doit apparaître cette information.

 

Comment faut il faire pour identifier les facteurs sur lesquels porte l'étude ?

La question semble très « plateforme » / « simulation » spécifique. (ISIS)

exemple :

un fichier qui décrit l'ensemble des paramètres possibles du modèles est injecté dans simExplorer, celui-ci construit un ExpDesign des paramètres qui varieront pour l'étude et l'envoie au simulateur. Comment construire cette liste ?

Semble plus une question entre une plateforme et le fichier XML qui décrit le plan d'exp que un pb entre le fichier expDesign et la construction du plan d'exp.

La question est peut-être prématurée, mais elle correspond à une demande des utilisateurs. Nous devons réfléchir à un interfaçage plateforme « générique » : décrire les «éléments » que les utilisateurs sont susceptibles de faire varier dans leur modèle.

L'attribut statut à une rôle informatif de l'état du processus en cours

 

Le code sera déposé sur la forge le plus rapidement possible

 

Confirmation de la prochaine réunion (physique) le 16 février.

Message de confirmation début janvier.

Le lieu est à fixer

Réunion BAO Mexico du 13 septembre 2010

Organisation

Lieu

salle 102, rue Jean Nicot (code porte C7575) de 10h à 16h30

Personnes présentes

Jean Couteau, Robert Faivre, Thierry Faure, Stéphanie Mahévas,

Hervé Monod, Benjamin Poussin, Hervé Richard, Juhui Wang

Objectif

Avancement de la librairie MTK

Discussions/Décisions

Rappel sur l'état d'avancement de la librairie

• Diagramme de classes et structure générale du code (en annexe, Section 5)

  → discussion sur l'intérêt de name et id

   

• Principales classes et leurs méthodes

  -- (NB : manque le descriptif des classes dans le manuel en ligne (à corriger)).

   

• Modèles et méthodes d'analyse de sensibilité implémentées

   

  → remarque sur le 1er run de l'exemple de ishigami (dans le répertoire demo du package) : plutôt faire un init qu'un run même si on « perd » un peu d'homogénéité dans l'appel

Organisation du projet

• Point sur l'installation sous la forge

→ voir les pages Web de support :

http://www.reseau-mexico.fr/devTools

 

• Fonctionnement pour les développeurs/les testeurs:

→ faciliter l'intégration d'une nouvelle méthode par un développeur méthodo

Il faut concevoir et documenter une façon simple d'ajouter de nouvelles méthodes d'analyses pour que chaque développeur méthodo puisse le faire sans difficulté, exemple d'étapes à suivre :

• construire une classe mtkRobertSampler.R

• construire une classe resultRobertSampler.R

…

Décrire la manip dans un tutoriel, éventuellement l'automatiser

→concernant les tests : ils sont de 2 niveaux :

• Constituer un jeu d'instructions et d'exemples qui permette de vérifier que le code traverse les modifications (rôle de de l'équipe dev; intérêt à évaluer de la librairie Runit)

• Pouvoir tester une nouvelle méthode ajoutée et vérifier son bon fonctionnement (intégrer les principes à suivre aux spécifications pour intégrer de nouvelles méthodes).

Développements/tâches à prévoir à court/moyen terme

• Interfaçage pour un utilisateur de R

  Ce point a été identifié comme important pour faciliter les échanges entre développeurs et testeurs statisticiens ou modélisateurs. Il s'agit de spécifier la gestion des informations et des fonctions par un utilisateur de R, en complément au fonctionnement par schémas XML.

  Voir le document mtkSpecsForRUsers.pdf

• Ordre de priorité sur les méthodes à implémenter

• Organisation des tests

• Intégration avec les plates-formes

• Autres à préciser

Discussion

• MtkExpFactors : concernant la méthode pour construire la liste de facteurs, RF signale sa préférence pour une manipulation de matrices de la même manière que pour l'EC (objet « .factor »).

→ le groupe valide cette approche : reprendre la classe pour ajouter ce constructeur

 

• mtkExperiment : il est intéressant de faire cohabiter différentes implémentations des méthodes (ex : plusieurs codage de Morris) peut se faire en combinant l'argument « site » avec l'arg « method »

→ validation de mtkExperiment

 

• implémenter les méthodes plot, summary, print, show (reste à définir ce que doivent faire ces méthodes)

→ spécifier les méthodes et les implementer

 

• comment sérialiser les données du workflow à l'extérieur pour que les étapes puissent être lancées ?

  • Proposition de JW créer une classe par plateforme, ex : mtkIsisSimulator.

  • Il faut pouvoir externaliser les données de chaque processus. Sous quel format ? XML ou scan R ? faut il des méta données. Dump, CSV, XML, ...

    Avis de TF : utiliser un data.frame permet d'avoir des données déjà structurées un minimum, sinon le risque est grand d'avoir à spécifier l'univers

→ On expérimente sur des exemples pour voir l'allure des donnés à sauvegardées. → Définir la procédure

 

• Nouvelles méthodes à implémenter :

  il faut avoir sensitivty (Sobol, Morris, Fast) à suivre Planor (moins simple), multisensi (HM), méta-modèles basés sur la régression (RF)

  TF propose d'intégrer LHS et sample (?)

• intégration sur les plateformes : TF souhaite annonce l'intégration des appels à MTK dans SimExplorer assez rapidement

• JC signale le paquet « login » pour le log des bug

• le process est éclaté pour chaque processus

Synthèse-conclusions

En particulier: retour rapide sur les perspectives à court et moyen terme, point sur les forces en

présence et à mobiliser (partenaires, stagiaires, etc), répartition des tâches et calendrier prévisionnel.

 

L'objectif est d'avoir une librairie opérationnelle dans son ensemble (stabilisée dans son architecture et dans son mode de fonctionnement et de développement; documentée) à la fin de l'année.

 

Une visio est programmée le 23/11/2010

 

D'ici là, les tâches prioritaires sont les suivantes, avec entre parenthèses les personnes les plus concernées:

• mettre à jour le contenu de mtkforRusers.pdf (HM)

• mettre à jour les méthodes de déclaration des facteurs (HR)

• préciser et documenter l'intégration de nouvelles méthodes (HM, RF)

• valider et compléter la base d'exemples (ishigami et fast/morris, wwdm et morris, exemple Jouy avec simulateur externe – autres contributions à préciser) (HM et JHW pour Jouy; autres à préciser)

• préciser les formats et protocoles d'import-export aux différentes étapes (plans d'expériences, simulations, résultats): à faire en priorité car peut impacter sur l'architecture. Prévoir le fonctionnement tout intégré sous R et le fonctionnement parsé/sérialisé piloté de l'extérieur (JHW, HM, appui Code Lutin)

• avancer sur les tests (JHW avec Ronan Trepos sur Runit, appui Code Lutin + Cemagref)

• autant que possible ajouter quelques méthodes (HM, RF, TF)

 

 

Diagramme de classes