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