Concepts mise en oeuvres

Concepts mise en oeuvres hrichard

Ce livre décrit les différents concepts mis en oeuvre dans la Boite à outils MEXICO;

La BaO Mexico est composée d'un ensemble de programmes simplifiant l’exploration de modèles complexes, on trouve :

La gestion de l’ensemble de cette BaO Mexico se fait à l’aide de la forge logicielle du département MIA de l’INRA. Cela permet notamment de versionner le code source et de centraliser les documents.

Terminologie

Terminologie hrichard
une terminologie commune

Malgré nos cultures différentes, nous devons tous utiliser le même langage, d'ou la nécessité de redéfinir certains termes utilisés. La liste qui suit est une ébauche réalisée par le groupe au tout début, il est nécessaire de mieux la completer.

Plateforme d'expérimentation : souvent abrégé pour Plateforme, désigne le logiciel pilotant les expérimentations qui est propre à un des participants du groupe (ex: ISIS-Fish, SimExplorer, VLE, Mobydic, …)

Facteur : une valeur qu'on s'autorise à faire varier pendant un plan d'expérience mais qui reste fixe pour une simulation

Domaine : ensemble de valeurs pour un facteur défini par expression (mathématique, géométrique … évaluée) ou extension (énumération).

Une spécification d’un plan d’expérience : Facteurs, espace de ces facteurs (domaine), méthode de parcours de l'espace de ces facteurs, définition des réplicats et définition de la graine de générateur du plan et de la graine du simulateur ou des réplicats.

Une instance du plan d'expérience : une réalisation d’un plan (communément un plan d'expérience).

Une élément du plan d'expérience (itération, item) : affectation à chaque facteur d'une valeur de son espace (vecteur de valeurs).

Réplicateur : Gestionnaire de réplicats

Réplicat : le résultat d'une exécution du modèle pour une instance du plan d'expérience.

Simulation : une exécution du modèle d'une instance du plan d'expérience, une seule fois (un run). Une simulation = un réplicat.

Conditions initiales : l'état des variables au temps t=0.

Un générateur de plan renvoie soit :

Soit une instance de plan

Soit un élément (itération, item)

valeur : entier, réel, chaîne

Comment décrire les facteurs dans MTK ? Réflexions.

Comment décrire les facteurs dans MTK ? Réflexions. hrichard

 

Janv. 2011
 
 
HM
Conventions pour déclarer des facteurs d'entrée à travers un tableur :
  • LIGNES
    1 ligne par facteur + une ligne de noms de colonnes
  • COLONNES
    1. une 1ère série de colonnes avec des noms obligés reprenant à peu près ceux du schéma XML: name, id, nominalValue, distribName
    2. pour déclarer les paramètres des distributions, deux options:
      1. une colonne unique "distribParam",dans ce cas, les paramètres sont insérés dans chaque ligne sous la forme "param1=valeur1::param2=valeur2". Le signe "=" est imposé, le séparateur "::" pourrait être modifiable (par un argument de la fonction de lecture du tableau).
        Remarque: cette option est particulièrement adaptée au cas où les distributions sont différentes selon les facteurs
      2. une série de colonnes intitulées "distribParam_parami", où "parami" est le nom du paramètre considéré
        Remarque: cette option est particulièrement adaptée au cas où la même famille de distributions est utilisée pour tous les facteurs
    3. une colonne "levels" pour les facteurs discrets dont on donne les niveaux explicitement (voir l'exemple scrapie). Dans ce cas, les niveaux sont insérés sous la forme "niveau1::niveau2::niveau3".
      Même remarque que ci-dessus pour le séparateur ::
    4. des colonnes supplémentaires de nom libre, qui seront considérées comme des "features" de même nom que celui de la colonne (voir nlevels dans l'exemple scrapie)
 
Remarques supplémentaires:
  • à part les colonnes "name" et "distribName", toutes les colonnes sont potentiellement manquantes
  • si "id" manque, le considérer comme égal à "name"
  • les fichiers ci-joints sont des implémentations sous OpenOffice de cette proposition pour tous les exemples de l'Ecole-Chercheurs + le modèle scrapie de Suzanne. L'idée est que l'utilisateur exporte ce tableau sous un format texte (.csv par exemple) et c'est ce fichier que l'on lit depuis R. Il est possible en principe de lire directement ces tableaux .ods depuis R, mais on peut voir cela dans un 2nd temps à mon avis.
  • a priori, on peut prévoir l'algo suivant:
    • a) lire le tableau par read.table(),
    • b) traiter les différentes colonnes selon la partition faite plus haut;
    • c) dénouer les items dans lesquels on a utilisé le séparateur de type :: (distribParam et levels)
  • attention, j'ai utilisé des "," (virgules) pour les nombres décimaux car sinon OpenOffice voulait transformer mes nombres en dates.
  • reste à envisager le cas où l'on déclare ce genre d'infos directement de R
     
RF
Est il possible de pouvoir définir une distribution continue restreinte à un support compact ?
En gros, si on veut une loi gaussienne de paramètres mu et sigma2 mais uniquement sur un intervalle a-b. Certes, ce n'est plus une "vraie gaussienne" mais j'ai l'impression qu'il y en a qui pourrait vouloir le faire.

Est-ce que ce que fungusPlus est envisageable ?

 
HM
Il y a des fonctions pour lois tronquées dans la librairie R de l'Ecole-Chercheur (fichier TPLibUtile.R, ligne 1118). Elles avaient été fournies par Bertrand.

En fait il y en a 2 types:

  • des fonctions pour des lois tronquées spécifiques:
dtnorm   ptnorm   qtnorm   rtnorm
dtlnorm  ptlnorm  qtlnorm  rtlnorm
dtgumbel ptgumbel qtgumbel rtgumbel
Dans ce cas on pourrait les considérer comme les autres lois, avec un min et un max.
 
  • des fonctions d.trunc.distr p.trunc.distr q.trunc.distr r.trunc.distr qui font les calculs de lois tronquées quelconques. Mais là encore on peut le traiter comme un cas particulier, en choisissant "trunc" comme nom de distribution et la loi en question comme paramètre.
Ton tableau montre qu'il serait bien de prévoir le cas où il y a à la fois une colonne "distribParam" et des colonnes "distribParam_toto"
 
 

Exemples

On peut retrouver les exemples sous forme de fichier .ods sous l'arborescence du projet "boite à outil Mexico" sur la forge MulCyber ( rubrique "Uncategorized Submissions") :  https://mulcyber.toulouse.inra.fr/docman/index.php?group_id=105

fungusFactors

id name nominalValue distribName distribParam_min distribParam_max
Tmax Tmax 4,5 unif 2,6 6
Tmin Tmin 9 unif 8 10
Topt Topt 20 unif 1,8 22
Wmax Wmax 4,5 unif 4 5
Wmin Wmin 9,5 unif 8 11
 
fungusFactorsPlus
id name nominalValue distribName distribParam distribParam_min distribParam_max
Tmax Tmax 4,5 norm mu=4::sigma=1 2,6 6
Tmin Tmin 9 unif   8 10
Topt Topt 20 unif   1,8 22
Wmax Wmax 4,5 unif   4 5
Wmin Wmin 9,5 unif   8 11
 
ishigamiFactors
name id nominalValue distribName distribParam
x1 x1 0 unif min=-3.14::max=3.14
x2 x2 0 unif min=-3.14::max=3.14
x3 x3 0 unif min=-3.14::max=3.14
 
 
 
scarpieFactors
name id nominalValue distribName distribParam levels nLevels
breed breed autorenov discreteNonOrdered   autorenov::perte1::pertemax 3
intro intro 0 sequence begin=0::end=2::step=1   3
 
 
weedsFactors

name nominalValue distribName distribParam_min distribParam_max
mu 0,84 unif 0,756 0,924
v 0,6 unif 0,54 0,66
phi 0,55 unif 0,495 0,605
beta.1 0,95 unif 0,855 1,045
beta.0 0,2 unif 0,18 0,22
chsi.1 0,3 unif 0,27 0,33
chsi.0 0,05 unif 0,045 0,055
delta.new 0,15 unif 0,135 0,165
delta.old 0,3 unif 0,27 0,33
mh 0,98 unif 0,882 1,078
mc 0 unif 0 0,5
Smax.1 445 unif 400,5 489,5
Smax.0 296 unif 266,4 325,6
Ymax 8 unif 7,2 8,8
rmax 0,002 unif 0,0018 0,0022
gamma 0,005 unif 0,0045 0,0055
delta.new 400 unif 300 500
Smax.0 10000 unif 7500 12500
SSBa 3350 unif 2512,5 4187,5
DSBa 280 unif 210 350
 
 
wwdmFactors
name nominalValue distribName distribParam levels nLevels
A 1,85 unif min=0,9::max=2,8    
B 0,94 unif min=0,9::max=0,99    
C 0,70 unif min=0,6::max=0,8    
D 7,50 unif min=3::max=12    
E 0,01 unif min=0,0035::max=0,01    
F 0,00 unif min=0,0011::max=0,0025    
G 900,00 unif min=700::max=1100    
Y 3,00 sequence begin=1::end=14::step=1    
 

 

Compléments sur la définition des facteurs

Compléments sur la définition des facteurs hmonod

Ci-dessous un texte rédigé à la suite de notre réunion début juillet, qui peut éclairer certains choix proposés dans le schéma XML.

 


Proposition sur la définition des facteurs pour le schéma expDesign XML de la BaO Mexico
 


HM, le 4/7/09
 


Introduction

 


Suite à la réunion des 2 et 3 juillet 2009 à Paris, l'un des éléments à finir de préciser concernait la  façon de décrire les facteurs du plan d'expériences. Ci-dessous une proposition qui vise à simplifier et à favoriser la généricité, en tenant compte des différents échanges au cours de la réunion. Le lien avec la description des facteurs sous R est également discuté. La redondance de certaines informations dans le schéma XML est évitée, me semble-t-il, ainsi que la complication qui résulterait de vouloir traiter trop de cas particuliers dans la structure même du schéma.
 


Proposition pour le schéma XML
 


Principe

Un facteur est décrit par:
 -- un nombre restreint d'attributs (3 ou 4 vraiment essentiels, par exemple 'name', 'id', 'unit');
 -- un élément DOMAINE;
 -- une liste ouverte d'éléments FEATURE (sans vouloir forcément imposer ce terme).

Le DOMAINE est décrit systématiquement sous la forme d'une distribution de probabilité, c'est-à-dire par:
-- les attributs 'distributionName' (obligatoire) et 'nominalValue'  (facultatif)
-- une liste ouverte d'éléments 'distributionParameter', d'attributs 'name' et 'value', qui précisent la distribution choisie;
-- lorsque le facteur est catégoriel, la liste de ses niveaux, par une liste ouverte d'éléments 'level', d'attributs 'value' et 'weight')
   [voir plus bas pour les différentes façons de simplifier cette déclaration de niveaux].

Les FEATURE ont un attribut 'name' et un attribut 'value'. Ils permettent de préciser les caractéristiques des facteurs nécessaires pour certaines méthodes. Par rapport aux discussions du 3 juillet, certaines caractéristiques des facteurs mises dans les attributs seraient plutôt gérées comme des features, par exemple:
-- 'nlevels' (un nombre, nécessaire pour les facteurs continus quand on utilise certains plans factoriels),
-- 'ordered' (TRUE/FALSE, nécessaire pour les facteurs discrets dans les méthodes qui exploitent cette distinction),
-- 'group' (un nombre ou une chaine de caractères, nécessaire pour les méthodes qui regroupent certains indices par groupes de facteurs),
-- 'type' (pour distinguer variable de décision, paramètre incertain, et variable d'entrée du modèle code),
-- etc.
 


Exemples (désolé si ma syntaxe n'est pas très claire)
 



<FACTEUR name="A" id="tauxCroissance" unit="g/jour">
-> <DOMAINE distributionName="uniforme" nominalValue=18>
   ->  <distributionParameter name="min" value=12>
   ->  <distributionParameter name="max" value=24>
-> <feature name="group" value="croissance">
-> <feature name="type" value="modelParameter">
-> <feature name="nlevels" value=5>

<FACTEUR name="B" id="departement">
-> <DOMAINE distributionName="categorical" nominalValue="Morbihan">
   ->  <level name="Morbihan" weight=2>
   ->  <level name="Charente" weight=1>
   ->  <level name="Finistère" weight=1>
-> <feature name="group" value="origine">
-> <feature name="type" value="inputVariable">

<FACTEUR name="C" id="age" unit="mois">
-> <DOMAINE distributionName="sequence" nominalValue=3>
   ->  <distributionParameter name="min" value=1>
   ->  <distributionParameter name="max" value=5>
   ->  <distributionParameter name="step" value=2>
-> <feature name="group" value="croissance">
-> <feature name="type" value="inputVariable">
 


Commentaires
 



*** Sur les features:

Beaucoup d'autres possibilités de features peuvent apparaitre lorsque les méthodes se développeront, c'est pouquoi il est important de laisser la liste ouverte. Bien entendu, certains des features sont appelés à être appelés fréquemment et il faudra choisir soigneusement comment les
définir. Mais cela relèvera des méthodes plutôt que de la définition de la structure XML proprement dite.

*** Sur les distributions:

On abandonne, avec cette proposition, la distinction explicite entre facteurs continus, discrets ordonnés et discrets non ordonnés. L'utilisation d'une telle typologie sera gérée directement par
les méthodes ou par un parser en amont des méthodes. L'idée est que distribName contient déjà l'information sur la nature (continue, discrète, ordonnée) du facteur, donc pas besoin d'en rajouter. Et s'il le faut pour une application, on pourra toujours passer par une feature.

Pour les termes à employer, l'idée est d'utiliser au maximum la terminologie de R pour le nom des distributions et le nom des paramètres. Cela couvrira beaucoup de cas, dont le cas standard de la
distribution uniforme sur un intervalle défini par un min et un max. Pour le cas des facteurs discrets, il faudra définir un ou deux noms de distribution propres à la BaO pour gérer les différents cas de
figure. Par exemple:
 -- distribName='categorical' pour les facteurs discrets non ordonnés  dont on donne explicitement la liste des niveaux et (éventuellement)  des pondérations
 -- distribName='sequence' pour les facteurs discrets (ordonnés ou non),  dont les niveaux sont décrits selon la syntaxe de la commande 'seq()'  de R.
 
 

Questions ISIS vs expDesign.xsd Rev 3

Questions ISIS vs expDesign.xsd Rev 3 hrichard

 

Questions
Factor

id et name ne sont ils pas redondants ?

feature a quoi ca sert ?

level,préciser un peu (est-ce un niveau de facteur discret sans distribution)

quel est l'intérêt de l'unité ?

dans process a quoi sert type ?

workflow a quoi sert name? type? et n'est ce pas redondant avec call

 

Remarque

Problème avec le workflow : call supporte déjà les paramètres normalement . il faut avoir une discussion autour du call pour les paramètres

Pour l'évaluation est-ce un run de chaque scenario ou de l'ensemble des scenarii en même temps?

 

Modifications a faire
factor

sur chaque factor il faudrait avoir une variable qui permette de préciser le type du facteur (discret - peut-être même distinguer numérique,non numérique- continu)

il manque target dans factor

domain

il faut que Nominalvalue soit un élément et non un type, car sinon difficile de mettre des matrices ou des équations.

il faut modifier la syntaxe des matrices pour avoir plus de 2 dimensions possibles (reprendre la représentation du outputData.xsd)

distributionParameter

il faut que value soit un élément pour permettre de mettre une matrice

level

il faut que value soit un élément pour permettre de mettre une matrice. Il faut quelque chose pour permettre d'avoir en value de level de quoi passer un nom et des paramètres (il faut aussi permettre de mettre des listes)

list

dans les listes il faut pouvoir mettre des <call> (besoin pour les Rules) .

worflow

Dans le workflow il faut pouvoir référencer le XML du scenario qui sera exécuté

 

Éléments de réponses aux Questions ISIS vs expDesign.xsd Rev 3

Éléments de réponses aux Questions ISIS vs expDesign.xsd Rev 3 hrichard

 

Questions
Factor

id et name ne sont ils pas redondants ?

Il s'agit tous les deux d'attributs de type identifiant. "Name" permet de donner au facteur, pour le plan d'expériences, un nom qui pourait être différent du nom utilisé dans le modèle de simulation. ID correspond au nom du facteur utilisé dans le modèle de simulation. Ceci permet de faciliter le mapping entre les noms des facteurs utilisés dans le modèle de simulation et ceux utilisés dans le logiciel de génération des plan d'expériences.

feature a quoi ca sert ?
feature a été introduit afin de rendre la définition du facteur plus souple et plus simple. Les propriétés 'évidentes' d'un facteur telles que son nom, son domaine de définition etc sont définies dans les attributs ou éléments explicites associés aux facteurs. "feature" permet d'apporter des informations supplémentaires pour mieux spécifier les facteurs quand une méthode le nécessite. Par exemple: a) pour les facteurs continus, nous avons introduit un "feature" nommé 'nlevels' qui permet de préciser que seuls 'nlevels' niveaux du facteur devraient être pris en compte dans le plan d'expérience généré: c'est un besoin assez particulier rencontré avec les plans factoriels classiques. b) pour préciser le type lexical des niveaux du facteur, on a introduit un feature nommé 'type' qui peut prendre comme valeur: string, integer, float, double, etc. Ceci facilitera les traitements des facteurs avec les programmes informatiques. c) pour les facteurs structurés en groupe, nous avons introduit un feature 'group'  qui permet d'expliciter les facteurs appartenant à un groupe spécifique, etc. 
 

level,préciser un peu (est-ce un niveau de facteur discret sans distribution)

Cet attribut a été introduit afin de déclarer explicitement les différents niveaux du facteur discret ordonné ou non-ordonné comme vous l'avez deviné dans vos messages.

Comme Nicolas l'a dit: ceci permet d'apporter des informations sémantiques aux facteurs, en l'occurence l'unité de mesure de leurs niveaux. Cela peut être utile lors de la restitution de résultats, par exemple dans des graphiques.

quel est l'intérêt de l'unité ?

dans process a quoi sert type ?

workflow a quoi sert name? type? et n'est ce pas redondant avec call

N'ayant pas participé à la spécification de cette partie du schéma, on laisse les autres y répondre ou ajouter des commentaires.

 

 

Remarque

Problème avec le workflow : call supporte déjà les paramètres normalement . il faut avoir une discussion autour du call pour les paramètres

Pour l'évaluation est-ce un run de chaque scenario ou de l'ensemble des scenarii en même temps?

 

Modifications a faire
factor

sur chaque factor il faudrait avoir une variable qui permette de préciser le type du facteur (discret - peut-être même distinguer numérique,non numérique- continu)

Dans la version du schéma proposée, ceci pourrait être résolu par l'utilisation de distributions "conventionnées Mexico", complétant les noms classiques de distributions.

Par exemple:

"categorical" → facteur discret non ordonnée

"discrete" → discret ordonné

"continuous uniform" → distribution uniforme sur un intervalle continu, etc.

 

Pendant la réunion de juillet, nous avons en effet beaucoup discuté de la typologie des distributions, sans réussir à converger. L'idée de la proposition est donc de ne pas avoir une distinction explicite des natures de facteurs dans le schéma XML, mais  d'en avoir une implicite à l'aide des noms de distribution (dont la signification exacte serait explicitée dans le manuel d'utilisation du schéma et gérée à l'étape de parsing ou d'appel d'une méthode). Cette approche apporte une meilleure extensibilité au schéma. En ce qui concerne la distinction "numérique", "non numérique", "continu", cela peut être géré de la même façon implicite: si une distribution est normale, elle est donc numérique et continue, si une distribution est "categorical", elle est donc discrète, etc. Ce type de distinction pourrait aussi, éventuellement, être géré par un "feature", mais cela ne nous parait pas forcément nécessaire.

       

il manque target dans factor

Est-ce que l'attribut 'ID' tel qu'il est défini auparavant permet de jouer le rôle du target?

domain

il faut que Nominalvalue soit un élément et non un type, car sinon difficile de mettre des matrices ou des équations.

Voir la partie 'Question" pour la prise en compte des facteurs matrice.

il faut modifier la syntaxe des matrices pour avoir plus de 2 dimensions possibles (reprendre la représentation du outputData.xsd)

 

distributionParameter

il faut que value soit un élément pour permettre de mettre une matrice

level

il faut que value soit un élément pour permettre de mettre une matrice. Il faut quelque chose pour permettre d'avoir en value de level de quoi passer un nom et des paramètres (il faut aussi permettre de mettre des listes)

list

dans les listes il faut pouvoir mettre des <call> (besoin pour les Rules) .

worflow

Dans le workflow il faut pouvoir référencer le XML du scenario qui sera exécuter

Nos questions et commentaires

1) Dans la proposition de Stéphanie, il y a un facteur nommé 'Nephrops Capturability' dont la définition nécessite la manipulation de matrices de dimension 10x3.

Avec le schéma actuel, une solution consiste à considérer que ce facteur se décompose en 10x3=30 facteurs, groupés en 10+3=13 groupes dans lesquels chaque ligne de la matrice forme un groupe (L1,..., L10) et chaque colonne forme aussi un groupe (C1, ..., C3). Ainsi, par exemple, l'élément  à la position de la matrice (1,1) peut être considéré comme un facteur structuré appartenant à la fois au groupe L1 et C1.

Une autre solution consiste à décomposer le facteur "matriciel" en 10x3=30 sous-facteurs et à introduire un nouveau "feature" nommé "matrix" en précisant explicitement la position du sous-facteurs dans la matrice par des features "row" et "column". *

2) On a du mal à saisir la subtilité du facteur "Rule Configuration". Est-ce que vous pouvez donner une brève déscription de ce facteur afin qu'on puisse regarder si avec le schéma actuel, on peut le définir convenablement ou quelles modifications à apporter si nécessaire?

3) On a intéret à soigner les choix du type des éléments et des attributs du schéma. Par exemple, préciser que l'attribut "author" est du type "string" au lieu de "anySimpleType", l'attribut 'date" est du type 'date' au lieu de 'anySimpleType', etc.

4) On a besoin plus de précision pour la spécification du workflow: quels sont les processus à inclure et comment les définir et comment traduire les paramètres spécifiés dans le schéma XML en appel des applications et comment enchaîner les processus?