impact de la mise en place d'un pas de temps hebdo ?
Salut, Voila une petite réflexion rapide sur le pas de temps dans Isis (il manque sûrement des choses, donc il faut compléter) La demande initial est de pouvoir faire un pas de temps hebdomadaire. Les problèmes à un changement de pas de temps ============================================= - tout ce qui est migration vérifie les choses par rapport au mois, il faudrait que dans l'objet Month, on puisse avoir en plus la notion de quart de mois (=1semaine). - Les résultats se font avec des matrices mensuelles, il faudrait qu'en fonction du pas de temps choisi cette dimension puisse varier. - les saisons sont définis par un interval de mois - des Rules et autres scripts utilisent le mois pour faire des choses. Quelques pistes pour y arriver ============================== 1ère solution ------------- l'idée sera de pouvoir définir en paramétrage de simulation la division de l'année souhaitée. (1=année, 4=saison, 12=mois, 52=semaine, 365=jour) - L'objet TimeStep prendrait donc cette valeur comme pas de temps pour la simulation - TimeStep pourrait retourner des objets Year et YearStep (division courante de l'année. Ex: si 4 division d'année, 3 retourne l'equivalent des 3 derniers mois de l'année. si 12 divisions d'annee, 11 retourne l'equivalent du mois de décembre, ...) - Il serait agréable que lors de la division de l'année, l'utilisateur puisse déterminé le nom qu'il souhaite donnée à chaque division (si division en 12 alors janvier, fevrier, ...) Des propositions par défaut serait données, exemple division par 6 alors on propose (janvier/fevrier, mars/avril, mai/juin, ...) - il faudrait conserver une compatibilite avec l'existant, donc par defaut le decoupage est mensuel et la method getMonth dans ce cas fonctionne. 2ème solution ------------- L'idée sera de basé la plus petite division à 1 jour (le plus pratique je pense, si on descend en dessous du jour ça va être compliqué) On indique ensuite avec combien de jour, on souhaite créer le pas de temps. 7=semaine, 30=mois, 90=trimestre, 360=année, 720=2 ans, ... et combien de pas de temps à une rotation (équivalent d'une année avec les mois), ceci est nécessaire pour la création des saisons. Par exemple si on a un pas de temps de 30 jours, on peut indique qu'on utilise 12 pas de temps pour définir une année. Mais on peut vouloir travailler avec des saisons bi-annuelle, dans ce cas, on pourrait indiquer qu'un rotation prend 24 pas de temps. - L'objet TimeStep prendrait donc cette valeur comme pas de temps comme incrément pour passer au pas de temps suivant pour la simulation - TimeStep pourrait retourner des objets Year(=360), Month=(30), Week=(7), Day=(1) quelque soit le le pas de temps choisi (toujours un multiple de jour) - La compatibilite avec l'existant est automatique si le pas est fixé a 30 et la rotation a 12 pas pour une année - il faut une méthode pour retourner le pas de temps courant dans la rotation choisi (0, 1, 2, ...) (step % stepByRotation). Ceci est nécessaire si on choisi un pas de temps différent de year, month, week, day. - je pense qu'il ne faut pas tenir compte des mois de 28, 29, 31 jours (beaucoup de complexite pour peu de plus value) - il faudra une option (case a cochée) dans le rendu des résulats pour indiquer si l'on veut les résultats sous forme d'année ou de rotation. Peut-etre meme un champs texte qui permette de définir l'affichage souhaite (ou une combo editable avec des valeurs par défaut existant, mais l'utilisateur pourra lui meme redéfinir ce qu'il souhaite) Par exemple pour un pas de temps de 30, une rotation de 720. Pour représenter la division 1500 avec: - %day = 1500 - %step = 50 - %stepInRotation r-%rotation = 1 r-2 (on suppose que le premier step est 0) - %month année %year = février année 4 La question a se poser est garde-t-on 0 comme valeur de premier élément ou on fini par prendre 1 ? Conclusion ========== La deuxième solution me semble beaucoup plus évolutive, elle permet de faire des pas de temps supérieurs à l'année, et de choisir sa rotation (on est plus obligé de suivre l'année). Par contre cette solution ne permet pas de faire une simulation sur un pas de temps inférieure au jour (au contraire de la 1ère). Mais ce n'est pas totalement vrai, il suffit de dire que la division minimal de 1 n'est pas un jour mais 1 heure, que la rotation est sur 8640 (dans ce cas les methodes year, month, ... retournent n'importe quoi, mais ceci n'a que peut d'importance, car ne servent a rien a part a affiche de facon plus agréable le pas de temps courant) Les changements a faire ======================= - TimeStep - PopulationSeasonInfoImpl - DefaultSimulator - verifier que les scripts utilise bien le nouveau TimeStep -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Bonjour à tous, j'imagine que ce sujet a été discuté hier durant le séminaire utilisateurs. et donc je n'ai pas les éléments qui conduisent à cette idée. du coup, ce que j'écris ne peut le prendre en compte Je me demande vraiment quelle est la pertinence de considérer un pas de temps hebdomadaire, voire journalier. Pour quel besoin de modélisation ? Plus l'échelle temporelle est fine, plus on va vers une description de type individu-centré (pour faire court) Que signifie un jour et même une semaine, pour une population qui est modélisée par lots d'individus identiques et à distribution homogène dans une zone à un moment donné ? ISIS a déjà du mal à gérer des applications avec de nombreuses mailles spatiales et on peut à peine faire 10 ans de simulation sur de telles applications; Faire exploser le nb de pas de temps ne va pas améliorer la performance Plus généralement, doit-on vouloir tout faire avec ISIS ? au risque de faire moins bien que d'autres modèles ciblés sur des échelles et des représentations précises. Ne faudrait-il pas mieux avoir plusieurs modèles séparés (des "ISIS-FILS") chacun destiné à des utilisations différentes ? par ex. un code pour une approche réellement spatiale, un pour une approche à échelle temporelle fine si c'est vraiment pertinent / modèle de base ISIS, ce dont je ne suis pas convaincue, L'idée de ISIS était de faire un modèle complexe mais parcimonieux et surtout de ne pas dériver vers une usine à gaz, ce qui peut se produire à force de rajouter des possibilités au gré des besoins individuels. C'est tout le souci, auquel on a veillé dès le départ de proposer un outil qui a de la flexibilité, mais qui a aussi une colonne vertébrale et un objectif précis. Merci de vos remarques et compléments d'information Dominique Le 06/12/2012 22:47, Benjamin POUSSIN a écrit :
Salut,
Voila une petite réflexion rapide sur le pas de temps dans Isis (il manque sûrement des choses, donc il faut compléter)
La demande initial est de pouvoir faire un pas de temps hebdomadaire.
Les problèmes à un changement de pas de temps ============================================= - tout ce qui est migration vérifie les choses par rapport au mois, il faudrait que dans l'objet Month, on puisse avoir en plus la notion de quart de mois (=1semaine). - Les résultats se font avec des matrices mensuelles, il faudrait qu'en fonction du pas de temps choisi cette dimension puisse varier. - les saisons sont définis par un interval de mois - des Rules et autres scripts utilisent le mois pour faire des choses.
Quelques pistes pour y arriver ==============================
1ère solution -------------
l'idée sera de pouvoir définir en paramétrage de simulation la division de l'année souhaitée. (1=année, 4=saison, 12=mois, 52=semaine, 365=jour)
- L'objet TimeStep prendrait donc cette valeur comme pas de temps pour la simulation - TimeStep pourrait retourner des objets Year et YearStep (division courante de l'année. Ex: si 4 division d'année, 3 retourne l'equivalent des 3 derniers mois de l'année. si 12 divisions d'annee, 11 retourne l'equivalent du mois de décembre, ...) - Il serait agréable que lors de la division de l'année, l'utilisateur puisse déterminé le nom qu'il souhaite donnée à chaque division (si division en 12 alors janvier, fevrier, ...) Des propositions par défaut serait données, exemple division par 6 alors on propose (janvier/fevrier, mars/avril, mai/juin, ...) - il faudrait conserver une compatibilite avec l'existant, donc par defaut le decoupage est mensuel et la method getMonth dans ce cas fonctionne.
2ème solution -------------
L'idée sera de basé la plus petite division à 1 jour (le plus pratique je pense, si on descend en dessous du jour ça va être compliqué)
On indique ensuite avec combien de jour, on souhaite créer le pas de temps. 7=semaine, 30=mois, 90=trimestre, 360=année, 720=2 ans, ...
et combien de pas de temps à une rotation (équivalent d'une année avec les mois), ceci est nécessaire pour la création des saisons. Par exemple si on a un pas de temps de 30 jours, on peut indique qu'on utilise 12 pas de temps pour définir une année. Mais on peut vouloir travailler avec des saisons bi-annuelle, dans ce cas, on pourrait indiquer qu'un rotation prend 24 pas de temps.
- L'objet TimeStep prendrait donc cette valeur comme pas de temps comme incrément pour passer au pas de temps suivant pour la simulation - TimeStep pourrait retourner des objets Year(=360), Month=(30), Week=(7), Day=(1) quelque soit le le pas de temps choisi (toujours un multiple de jour) - La compatibilite avec l'existant est automatique si le pas est fixé a 30 et la rotation a 12 pas pour une année - il faut une méthode pour retourner le pas de temps courant dans la rotation choisi (0, 1, 2, ...) (step % stepByRotation). Ceci est nécessaire si on choisi un pas de temps différent de year, month, week, day. - je pense qu'il ne faut pas tenir compte des mois de 28, 29, 31 jours (beaucoup de complexite pour peu de plus value) - il faudra une option (case a cochée) dans le rendu des résulats pour indiquer si l'on veut les résultats sous forme d'année ou de rotation. Peut-etre meme un champs texte qui permette de définir l'affichage souhaite (ou une combo editable avec des valeurs par défaut existant, mais l'utilisateur pourra lui meme redéfinir ce qu'il souhaite) Par exemple pour un pas de temps de 30, une rotation de 720. Pour représenter la division 1500 avec: - %day = 1500 - %step = 50 - %stepInRotation r-%rotation = 1 r-2 (on suppose que le premier step est 0) - %month année %year = février année 4
La question a se poser est garde-t-on 0 comme valeur de premier élément ou on fini par prendre 1 ?
Conclusion ==========
La deuxième solution me semble beaucoup plus évolutive, elle permet de faire des pas de temps supérieurs à l'année, et de choisir sa rotation (on est plus obligé de suivre l'année). Par contre cette solution ne permet pas de faire une simulation sur un pas de temps inférieure au jour (au contraire de la 1ère). Mais ce n'est pas totalement vrai, il suffit de dire que la division minimal de 1 n'est pas un jour mais 1 heure, que la rotation est sur 8640 (dans ce cas les methodes year, month, ... retournent n'importe quoi, mais ceci n'a que peut d'importance, car ne servent a rien a part a affiche de facon plus agréable le pas de temps courant)
Les changements a faire ======================= - TimeStep - PopulationSeasonInfoImpl - DefaultSimulator - verifier que les scripts utilise bien le nouveau TimeStep
-- Dominique PELLETIER Responsable de projet /Senior scientist/ Biodiversité et Aires Marines Protégées /Biodiversity and Marine Protected Areas/ /PAMPA project : //wwz.ifremer.fr/pampa/ <http://wwz.ifremer.fr/pampa/>/ /www.ifremer.fr/ncal/// IFREMER BP 2059, 98846 Nouméa Cedex Nouvelle-Calédonie Tél. (687) 292557 / 285171 Fax. (687) 287857
Salut Dominique
Merci pour ta réaction. Effectivement tout cela est le résultat de
discussions en amont de la réunion et pendant la réunion.
Un relevé de conclusions des deux jours de réunion sera envoyé jeudi. Tu
pourras voir la teneur de nos discussions.
Mais d'ici là, je vais faire une courte réponse aux différents points
pertinents que tu soulèves. On pourra aussi en reparler la semaine
prochaine.
> Je me demande vraiment quelle est la pertinence de considérer un pas
> de temps hebdomadaire, voire journalier.
> Pour quel besoin de modélisation ?
répondre à des questions de plus en plus actuelles au regard de la
nouvelle PCP (gestion temps réel) et de la DCSMM (micro-zones habitat).
> Plus l'échelle temporelle est fine, plus on va vers une description de
> type individu-centré (pour faire court)
je ne crois pas. Plus on diminue la résolution temporelle, plus on
décrire l'hétérogénéité spatiale de la population liée aux déplacements
(niveau de mobilité de la population) et aux multiples activités que
l'on observe avec les données VMS.
> Que signifie un jour et même une semaine, pour une population qui est
> modélisée par lots d'individus identiques et à distribution homogène
> dans une zone à un moment donné ?
les deux points doivent être traités en même temps. Toutes ces
hypothèses sont des hypotèses conjointes.
>
> ISIS a déjà du mal à gérer des applications avec de nombreuses mailles
> spatiales et on peut à peine faire 10 ans de simulation sur de telles
> applications;
> Faire exploser le nb de pas de temps ne va pas améliorer la performance
c'est pour ça que avec une telle résolution l'objectif ne sera pas
1. de tout modéliser
2. d'avoir des durées de simulation aussi importantes
Il se peut que dans certain cas, il ne soit possible que de faire de
l'exploration d'hypothèses.
>
> Plus généralement, doit-on vouloir tout faire avec ISIS ? au risque de
> faire moins bien que d'autres modèles ciblés sur des échelles et des
> représentations précises.
> Ne faudrait-il pas mieux avoir plusieurs modèles séparés (des
> "ISIS-FILS") chacun destiné à des utilisations différentes ?
> par ex. un code pour une approche réellement spatiale, un pour une
> approche à échelle temporelle fine si c'est vraiment pertinent /
> modèle de base ISIS, ce dont je ne suis pas convaincue,
on ne pourra dissocier les deux echelles (temporelle et spatiale). Le
choix du pas de temps mensuel dans ISIS, impose aussi d'une certaine
manière une résolution spatiale. Donc donner de la souplesse à
l'utilisateur (averti!) permettra de tester différentes hypothèses sur
le comportement de la population et des pêcheurs.
La question d'avoir plusieurs ISIS ne devrait pas se poser car pour
l'utilisateur non averti tout sera comme avant (resolution temporelle
par defaut = mois). Mais pas de soucis, on rediscutera de tout ça avant
le développement car aujourd'hui rien n'est fixé.
>
> L'idée de ISIS était de faire un modèle complexe mais parcimonieux et
> surtout de ne pas dériver vers une usine à gaz, ce qui peut se produire
> à force de rajouter des possibilités au gré des besoins individuels.
> C'est tout le souci, auquel on a veillé dès le départ de proposer un
> outil qui a de la flexibilité, mais qui a aussi une colonne vertébrale
> et un objectif précis.
oui je suis entièrement d'accord avec toi.
Mais qui peut le plus peut le moins. Il s'agit surtout de donner de la
flexibilité à ceux qui maitrisent l'outil.
C'est interessant de voir la diversité des niveaux de complexité entre
les différentes applications (ultra precises (cf Pélagique GdG de Sigrid
ou cohabitent des modèles spatiaux structurés en longueur et des modèles
globaux, ou celle de Bastien avec une resolution spatiale très fine) ou
moins fines (cf poissons plats Manche structurée en age et proche des
modèles d'evaluation). Il y a toujours quelques déboires dans le
processus de parametrisation mais au final tout le monde réussit à faire
tourner son appli et même à faire des analyses de sensibilité ou
d'incertitude!
>
> Merci de vos remarques et compléments d'information
on en reparle à Lorient
Bises
Stephanie
>
> Dominique
>
>
> Le 06/12/2012 22:47, Benjamin POUSSIN a écrit :
>> Salut,
>>
>> Voila une petite réflexion rapide sur le pas de temps dans Isis (il
>> manque sûrement des choses, donc il faut compléter)
>>
>> La demande initial est de pouvoir faire un pas de temps hebdomadaire.
>>
>> Les problèmes à un changement de pas de temps
>> =============================================
>> - tout ce qui est migration vérifie les choses par rapport au mois, il
>> faudrait que dans l'objet Month, on puisse avoir en plus la notion de
>> quart de mois (=1semaine).
>> - Les résultats se font avec des matrices mensuelles, il faudrait qu'en
>> fonction du pas de temps choisi cette dimension puisse varier.
>> - les saisons sont définis par un interval de mois
>> - des Rules et autres scripts utilisent le mois pour faire des choses.
>>
>> Quelques pistes pour y arriver
>> ==============================
>>
>> 1ère solution
>> -------------
>>
>> l'idée sera de pouvoir définir en paramétrage de simulation la division
>> de l'année souhaitée. (1=année, 4=saison, 12=mois, 52=semaine, 365=jour)
>>
>> - L'objet TimeStep prendrait donc cette valeur comme pas de temps pour
>> la simulation
>> - TimeStep pourrait retourner des objets Year et YearStep (division
>> courante de l'année. Ex: si 4 division d'année, 3 retourne
>> l'equivalent des 3 derniers mois de l'année. si 12 divisions d'annee,
>> 11 retourne l'equivalent du mois de décembre, ...)
>> - Il serait agréable que lors de la division de l'année, l'utilisateur
>> puisse déterminé le nom qu'il souhaite donnée à chaque division (si
>> division en 12 alors janvier, fevrier, ...) Des propositions par
>> défaut serait données, exemple division par 6 alors on propose
>> (janvier/fevrier, mars/avril, mai/juin, ...)
>> - il faudrait conserver une compatibilite avec l'existant, donc par
>> defaut le decoupage est mensuel et la method getMonth dans ce cas
>> fonctionne.
>>
>> 2ème solution
>> -------------
>>
>> L'idée sera de basé la plus petite division à 1 jour (le plus pratique
>> je pense, si on descend en dessous du jour ça va être compliqué)
>>
>> On indique ensuite avec combien de jour, on souhaite créer le pas de
>> temps. 7=semaine, 30=mois, 90=trimestre, 360=année, 720=2 ans, ...
>>
>> et combien de pas de temps à une rotation (équivalent d'une année avec
>> les mois), ceci est nécessaire pour la création des saisons. Par
>> exemple si on a un pas de temps de 30 jours, on peut indique qu'on
>> utilise 12 pas de temps pour définir une année. Mais on peut vouloir
>> travailler avec des saisons bi-annuelle, dans ce cas, on pourrait
>> indiquer qu'un rotation prend 24 pas de temps.
>>
>> - L'objet TimeStep prendrait donc cette valeur comme pas de temps comme
>> incrément pour passer au pas de temps suivant pour la simulation
>> - TimeStep pourrait retourner des objets Year(=360), Month=(30),
>> Week=(7), Day=(1) quelque soit le le pas de temps choisi (toujours un
>> multiple de jour)
>> - La compatibilite avec l'existant est automatique si le pas est fixé a
>> 30 et la rotation a 12 pas pour une année
>> - il faut une méthode pour retourner le pas de temps courant dans
>> la rotation choisi (0, 1, 2, ...) (step % stepByRotation). Ceci est
>> nécessaire si on choisi un pas de temps différent de year, month,
>> week, day.
>> - je pense qu'il ne faut pas tenir compte des mois de 28, 29, 31 jours
>> (beaucoup de complexite pour peu de plus value)
>> - il faudra une option (case a cochée) dans le rendu des résulats pour
>> indiquer si l'on veut les résultats sous forme d'année ou de rotation.
>> Peut-etre meme un champs texte qui permette de définir l'affichage
>> souhaite (ou une combo editable avec des valeurs par défaut existant,
>> mais l'utilisateur pourra lui meme redéfinir ce qu'il souhaite)
>> Par exemple pour un pas de temps de 30, une rotation de 720. Pour
>> représenter la division 1500 avec:
>> - %day = 1500
>> - %step = 50
>> - %stepInRotation r-%rotation = 1 r-2 (on suppose que le premier step
>> est 0)
>> - %month année %year = février année 4
>>
>> La question a se poser est garde-t-on 0 comme valeur de premier élément
>> ou on fini par prendre 1 ?
>>
>> Conclusion
>> ==========
>>
>> La deuxième solution me semble beaucoup plus évolutive, elle permet de
>> faire des pas de temps supérieurs à l'année, et de choisir sa rotation
>> (on est plus obligé de suivre l'année). Par contre cette solution ne
>> permet pas de faire une simulation sur un pas de temps inférieure au
>> jour (au contraire de la 1ère). Mais ce n'est pas totalement vrai, il
>> suffit de dire que la division minimal de 1 n'est pas un jour mais 1
>> heure, que la rotation est sur 8640 (dans ce cas les methodes year,
>> month, ... retournent n'importe quoi, mais ceci n'a que peut
>> d'importance, car ne servent a rien a part a affiche de facon plus
>> agréable le pas de temps courant)
>>
>> Les changements a faire
>> =======================
>> - TimeStep
>> - PopulationSeasonInfoImpl
>> - DefaultSimulator
>> - verifier que les scripts utilise bien le nouveau TimeStep
>>
>
> --
>
> Dominique PELLETIER
>
> Responsable de projet /Senior scientist/
>
> Biodiversité et Aires Marines Protégées
>
> /Biodiversity and Marine Protected Areas/
>
> /PAMPA project : //wwz.ifremer.fr/pampa/ <http://wwz.ifremer.fr/pampa/>/
>
> /www.ifremer.fr/ncal///
>
> IFREMER BP 2059, 98846 Nouméa Cedex
>
> Nouvelle-Calédonie
>
> Tél. (687) 292557 / 285171
>
> Fax. (687) 287857
>
>
>
> _______________________________________________
> Isis-fish-devel mailing list
> Isis-fish-devel@list.isis-fish.org
> http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
--
......................................................................
Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr)
IFREMER/EMH (Ecologie et Modèles pour l'Halieutique)
Tel: (33) 2 40 37 41 81 Fax: (33) 2 40 37 40 75
o \ o / _ o __| \ / |__ o _ \ o / o
/|\ | /\ ___\o \o | o/ o/__ /\ | /|\
/ \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \
......................................................................
Salut, je rejoins Stéphanie sur la plupart des réponses, je voulais simplement ajouter quelques éléments à la discussion. Comme je le disais à Stéphanie, je pense nécessaire d'ouvrir une réflexion sur les échelles appropriées pour répondre aux questions de gestion, d'un point de vue d'ISIS et de ces objectifs d'une part mais aussi de manière plus conceptuelle. Donc super que ca soit sur le tapis. Pour ce qui est du "plus c'est fin, plus on va vers de l'individu centré" je suis d'accord avec Dominique: si les processus déterministes ne sont pas connus, les utilisateurs vont être tentés de les rendre aléatoires, pas forcement jouable ou pire de faire des hypothèses encore plus fortes. La question se pose néanmoins comme le disait Stéphanie quand les échelles de description possibles ou nécessaires pour la gestion, l'activité de pêche et la biologie diffèrent. Jusqu'ici je dirais que la "complexification d'ISIS" par l'apport d'une plus grande flexibilité reflétait une prise de conscience d'hypothèses implicites mais déterminantes (cf simulateur par default / simulateur per cell) et qu'elle contribuait donc a une plus grande transparence des hypothèses du modèle (= force l'utilisateur a se poser ces questions). Le passage à l'échelle hebdomadaire me semble du même ordre d'idée: puis-je décrire de manière déterministe les processus migratoires à l'échelle de la semaine? si non, je fais l'hypothèse d'un brassage homogène de la pop à l'échelle du mois. Il serait sans doute bon dans la présentation du modèle sur le site web, de décrire avec des mots les hypothèses structurelles d'ISIS (les inchangeables) et les points flexibles avec les hypothèses sous-jacentes afin de permettre aux utilisateurs potentiellement intéressés de déterminer facilement si le modèle leur convient (même si tout est dans les équations ce n'est pas forcement facile à voir). De mon point de vue, ISIS est deja perçu comme une "usine a gaz" dans la communauté halieutique, vu le niveau de complexité de "la colonne vertebrale". Nous savons qu'il n'est pas necessaire de renseigner tous les parametres mais pour l'utilisateur qui voit les interfaces ca n'est pas evident (shunter des parametres et processus a decrire en mettant un 0 ou un 1 dans la case necessite de connaitre en detail les equations). Il faut vraiment qu'on communique la dessus. De mon expérience, les modèles comme ISIS attirent car on a pas à recoder tout, mais font peur car on ne contrôle pas toutes les hypothèses et on pourrait finir par adapter ses questions au modèle au lieu d'adapter le modèle aux questions. (C'est ce qui inquiétait mes encadrants aux US et les a poussé a me faire recoder un modèle matriciel spatialisé en R!!!). Il n'existe pas de plateformes alternatives a ISIS pour les modèles deterministes spatialisés (a part Atlantis mais c'est encore plus complexe), il y a une vraie carte a jouer. Enfin, je crois que de toutes facons ISIS necessite un minimum de comprehension des equations dans l'état, ne serait-ce que . Je serais heureuse de poursuivre la discussion avec vous la semaine prochaine. Bises Sigrid Le 11 décembre 2012 11:59, Stephanie MAHEVAS <Stephanie.Mahevas@ifremer.fr>a écrit :
Salut Dominique
Merci pour ta réaction. Effectivement tout cela est le résultat de discussions en amont de la réunion et pendant la réunion. Un relevé de conclusions des deux jours de réunion sera envoyé jeudi. Tu pourras voir la teneur de nos discussions. Mais d'ici là, je vais faire une courte réponse aux différents points pertinents que tu soulèves. On pourra aussi en reparler la semaine prochaine.
Je me demande vraiment quelle est la pertinence de considérer un pas de temps hebdomadaire, voire journalier. Pour quel besoin de modélisation ?
répondre à des questions de plus en plus actuelles au regard de la nouvelle PCP (gestion temps réel) et de la DCSMM (micro-zones habitat).
Plus l'échelle temporelle est fine, plus on va vers une description de type individu-centré (pour faire court)
je ne crois pas. Plus on diminue la résolution temporelle, plus on décrire l'hétérogénéité spatiale de la population liée aux déplacements (niveau de mobilité de la population) et aux multiples activités que l'on observe avec les données VMS.
Que signifie un jour et même une semaine, pour une population qui est modélisée par lots d'individus identiques et à distribution homogène dans une zone à un moment donné ?
les deux points doivent être traités en même temps. Toutes ces hypothèses sont des hypotèses conjointes.
ISIS a déjà du mal à gérer des applications avec de nombreuses mailles spatiales et on peut à peine faire 10 ans de simulation sur de telles applications; Faire exploser le nb de pas de temps ne va pas améliorer la performance
c'est pour ça que avec une telle résolution l'objectif ne sera pas 1. de tout modéliser 2. d'avoir des durées de simulation aussi importantes Il se peut que dans certain cas, il ne soit possible que de faire de l'exploration d'hypothèses.
Plus généralement, doit-on vouloir tout faire avec ISIS ? au risque de faire moins bien que d'autres modèles ciblés sur des échelles et des représentations précises. Ne faudrait-il pas mieux avoir plusieurs modèles séparés (des "ISIS-FILS") chacun destiné à des utilisations différentes ? par ex. un code pour une approche réellement spatiale, un pour une approche à échelle temporelle fine si c'est vraiment pertinent / modèle de base ISIS, ce dont je ne suis pas convaincue,
on ne pourra dissocier les deux echelles (temporelle et spatiale). Le choix du pas de temps mensuel dans ISIS, impose aussi d'une certaine manière une résolution spatiale. Donc donner de la souplesse à l'utilisateur (averti!) permettra de tester différentes hypothèses sur le comportement de la population et des pêcheurs. La question d'avoir plusieurs ISIS ne devrait pas se poser car pour l'utilisateur non averti tout sera comme avant (resolution temporelle par defaut = mois). Mais pas de soucis, on rediscutera de tout ça avant le développement car aujourd'hui rien n'est fixé.
L'idée de ISIS était de faire un modèle complexe mais parcimonieux et surtout de ne pas dériver vers une usine à gaz, ce qui peut se produire à force de rajouter des possibilités au gré des besoins individuels. C'est tout le souci, auquel on a veillé dès le départ de proposer un outil qui a de la flexibilité, mais qui a aussi une colonne vertébrale et un objectif précis.
oui je suis entièrement d'accord avec toi. Mais qui peut le plus peut le moins. Il s'agit surtout de donner de la flexibilité à ceux qui maitrisent l'outil. C'est interessant de voir la diversité des niveaux de complexité entre les différentes applications (ultra precises (cf Pélagique GdG de Sigrid ou cohabitent des modèles spatiaux structurés en longueur et des modèles globaux, ou celle de Bastien avec une resolution spatiale très fine) ou moins fines (cf poissons plats Manche structurée en age et proche des modèles d'evaluation). Il y a toujours quelques déboires dans le processus de parametrisation mais au final tout le monde réussit à faire tourner son appli et même à faire des analyses de sensibilité ou d'incertitude!
Merci de vos remarques et compléments d'information
on en reparle à Lorient Bises Stephanie
Dominique
Le 06/12/2012 22:47, Benjamin POUSSIN a écrit :
Salut,
Voila une petite réflexion rapide sur le pas de temps dans Isis (il manque sûrement des choses, donc il faut compléter)
La demande initial est de pouvoir faire un pas de temps hebdomadaire.
Les problèmes à un changement de pas de temps ============================================= - tout ce qui est migration vérifie les choses par rapport au mois, il faudrait que dans l'objet Month, on puisse avoir en plus la notion de quart de mois (=1semaine). - Les résultats se font avec des matrices mensuelles, il faudrait qu'en fonction du pas de temps choisi cette dimension puisse varier. - les saisons sont définis par un interval de mois - des Rules et autres scripts utilisent le mois pour faire des choses.
Quelques pistes pour y arriver ==============================
1ère solution -------------
l'idée sera de pouvoir définir en paramétrage de simulation la division de l'année souhaitée. (1=année, 4=saison, 12=mois, 52=semaine, 365=jour)
- L'objet TimeStep prendrait donc cette valeur comme pas de temps pour la simulation - TimeStep pourrait retourner des objets Year et YearStep (division courante de l'année. Ex: si 4 division d'année, 3 retourne l'equivalent des 3 derniers mois de l'année. si 12 divisions d'annee, 11 retourne l'equivalent du mois de décembre, ...) - Il serait agréable que lors de la division de l'année, l'utilisateur puisse déterminé le nom qu'il souhaite donnée à chaque division (si division en 12 alors janvier, fevrier, ...) Des propositions par défaut serait données, exemple division par 6 alors on propose (janvier/fevrier, mars/avril, mai/juin, ...) - il faudrait conserver une compatibilite avec l'existant, donc par defaut le decoupage est mensuel et la method getMonth dans ce cas fonctionne.
2ème solution -------------
L'idée sera de basé la plus petite division à 1 jour (le plus pratique je pense, si on descend en dessous du jour ça va être compliqué)
On indique ensuite avec combien de jour, on souhaite créer le pas de temps. 7=semaine, 30=mois, 90=trimestre, 360=année, 720=2 ans, ...
et combien de pas de temps à une rotation (équivalent d'une année avec les mois), ceci est nécessaire pour la création des saisons. Par exemple si on a un pas de temps de 30 jours, on peut indique qu'on utilise 12 pas de temps pour définir une année. Mais on peut vouloir travailler avec des saisons bi-annuelle, dans ce cas, on pourrait indiquer qu'un rotation prend 24 pas de temps.
- L'objet TimeStep prendrait donc cette valeur comme pas de temps comme incrément pour passer au pas de temps suivant pour la simulation - TimeStep pourrait retourner des objets Year(=360), Month=(30), Week=(7), Day=(1) quelque soit le le pas de temps choisi (toujours un multiple de jour) - La compatibilite avec l'existant est automatique si le pas est fixé a 30 et la rotation a 12 pas pour une année - il faut une méthode pour retourner le pas de temps courant dans la rotation choisi (0, 1, 2, ...) (step % stepByRotation). Ceci est nécessaire si on choisi un pas de temps différent de year, month, week, day. - je pense qu'il ne faut pas tenir compte des mois de 28, 29, 31 jours (beaucoup de complexite pour peu de plus value) - il faudra une option (case a cochée) dans le rendu des résulats pour indiquer si l'on veut les résultats sous forme d'année ou de rotation. Peut-etre meme un champs texte qui permette de définir l'affichage souhaite (ou une combo editable avec des valeurs par défaut existant, mais l'utilisateur pourra lui meme redéfinir ce qu'il souhaite) Par exemple pour un pas de temps de 30, une rotation de 720. Pour représenter la division 1500 avec: - %day = 1500 - %step = 50 - %stepInRotation r-%rotation = 1 r-2 (on suppose que le premier step est 0) - %month année %year = février année 4
La question a se poser est garde-t-on 0 comme valeur de premier élément ou on fini par prendre 1 ?
Conclusion ==========
La deuxième solution me semble beaucoup plus évolutive, elle permet de faire des pas de temps supérieurs à l'année, et de choisir sa rotation (on est plus obligé de suivre l'année). Par contre cette solution ne permet pas de faire une simulation sur un pas de temps inférieure au jour (au contraire de la 1ère). Mais ce n'est pas totalement vrai, il suffit de dire que la division minimal de 1 n'est pas un jour mais 1 heure, que la rotation est sur 8640 (dans ce cas les methodes year, month, ... retournent n'importe quoi, mais ceci n'a que peut d'importance, car ne servent a rien a part a affiche de facon plus agréable le pas de temps courant)
Les changements a faire ======================= - TimeStep - PopulationSeasonInfoImpl - DefaultSimulator - verifier que les scripts utilise bien le nouveau TimeStep
--
Dominique PELLETIER****
Responsable de projet *Senior scientist*****
Biodiversité et Aires Marines Protégées****
*Biodiversity and Marine Protected Areas*
*PAMPA project : **wwz.ifremer.fr/pampa/*
*www.ifremer.fr/ncal***
** **
IFREMER BP 2059, 98846 Nouméa Cedex****
Nouvelle-Calédonie****
Tél. (687) 292557 / 285171****
Fax. (687) 287857****
_______________________________________________ Isis-fish-devel mailing listIsis-fish-devel@list.isis-fish.orghttp://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
-- ...................................................................... Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr) IFREMER/EMH (Ecologie et Modèles pour l'Halieutique) Tel: (33) 2 40 37 41 81 Fax: (33) 2 40 37 40 75
o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \ ......................................................................
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
Le 11/12/2012 18:12, Sigrid Lehuta a écrit :
Salut,
je rejoins Stéphanie sur la plupart des réponses, je voulais simplement ajouter quelques éléments à la discussion. Comme je le disais à Stéphanie, je pense nécessaire d'ouvrir une réflexion sur les échelles appropriées pour répondre aux questions de gestion, d'un point de vue d'ISIS et de ces objectifs d'une part mais aussi de manière plus conceptuelle. Donc super que ca soit sur le tapis.
Pour ce qui est du "plus c'est fin, plus on va vers de l'individu centré" je suis d'accord avec Dominique: si les processus déterministes ne sont pas connus, les utilisateurs vont être tentés de les rendre aléatoires, pas forcement jouable ou pire de faire des hypothèses encore plus fortes. La question se pose néanmoins comme le disait Stéphanie quand les échelles de description possibles ou nécessaires pour la gestion, l'activité de pêche et la biologie diffèrent. augmenter la résolution spatiale et temporelle ne veut pas dire passer à de l'individu centré (ISIS propose une description groupe-centré ;-) ) mais signifie préciser la description de la variabilité spatio-temporelle de (chaque groupe de) la population. Ce qui est pertinent si on sait décrire les processus sous-jacents. C'est là tout l'intérêt de la souplesse pour un utilisateur qui sait utiliser le modèle de manière réflechie et pas simplement en remplissant des cases:-\ . Il sera important de bien dire que l'on ne va pas vers du poisson centré!
Jusqu'ici je dirais que la "complexification d'ISIS" par l'apport d'une plus grande flexibilité reflétait une prise de conscience d'hypothèses implicites mais déterminantes (cf simulateur par default / simulateur per cell) et qu'elle contribuait donc a une plus grande transparence des hypothèses du modèle (= force l'utilisateur a se poser ces questions). Le passage à l'échelle hebdomadaire me semble du même ordre d'idée: puis-je décrire de manière déterministe les processus migratoires à l'échelle de la semaine? si non, je fais l'hypothèse d'un brassage homogène de la pop à l'échelle du mois. Il serait sans doute bon dans la présentation du modèle sur le site web, de décrire avec des mots les hypothèses structurelles d'ISIS (les inchangeables) et les points flexibles avec les hypothèses sous-jacentes afin de permettre aux utilisateurs potentiellement intéressés de déterminer facilement si le modèle leur convient (même si tout est dans les équations ce n'est pas forcement facile à voir). c'est peut-être un élément que l'on pourrait ajouter dans la présentation des 4 modèles "opérationnels"? Ce sera plus facile sur des exemples concrets non?
De mon point de vue, ISIS est deja perçu comme une "usine a gaz" dans la communauté halieutique, vu le niveau de complexité de "la colonne vertebrale". Nous savons qu'il n'est pas necessaire de renseigner tous les parametres mais pour l'utilisateur qui voit les interfaces ca n'est pas evident (shunter des parametres et processus a decrire en mettant un 0 ou un 1 dans la case necessite de connaitre en detail les equations). Il faut vraiment qu'on communique la dessus.
De mon expérience, les modèles comme ISIS attirent car on a pas à recoder tout, mais font peur car on ne contrôle pas toutes les hypothèses et on pourrait finir par adapter ses questions au modèle au lieu d'adapter le modèle aux questions. (C'est ce qui inquiétait mes encadrants aux US et les a poussé a me faire recoder un modèle matriciel spatialisé en R!!!). Il n'existe pas de plateformes alternatives a ISIS pour les modèles deterministes spatialisés (a part Atlantis mais c'est encore plus complexe), il y a une vraie carte a jouer. Enfin, je crois que de toutes facons ISIS necessite un minimum de comprehension des equations dans l'état, ne serait-ce que .
Je serais heureuse de poursuivre la discussion avec vous la semaine prochaine. Bises Sigrid
Le 11 décembre 2012 11:59, Stephanie MAHEVAS <Stephanie.Mahevas@ifremer.fr <mailto:Stephanie.Mahevas@ifremer.fr>> a écrit :
Salut Dominique
Merci pour ta réaction. Effectivement tout cela est le résultat de discussions en amont de la réunion et pendant la réunion. Un relevé de conclusions des deux jours de réunion sera envoyé jeudi. Tu pourras voir la teneur de nos discussions. Mais d'ici là, je vais faire une courte réponse aux différents points pertinents que tu soulèves. On pourra aussi en reparler la semaine prochaine.
Je me demande vraiment quelle est la pertinence de considérer un pas de temps hebdomadaire, voire journalier. Pour quel besoin de modélisation ?
répondre à des questions de plus en plus actuelles au regard de la nouvelle PCP (gestion temps réel) et de la DCSMM (micro-zones habitat).
Plus l'échelle temporelle est fine, plus on va vers une description de type individu-centré (pour faire court)
je ne crois pas. Plus on diminue la résolution temporelle, plus on décrire l'hétérogénéité spatiale de la population liée aux déplacements (niveau de mobilité de la population) et aux multiples activités que l'on observe avec les données VMS.
Que signifie un jour et même une semaine, pour une population qui est modélisée par lots d'individus identiques et à distribution homogène dans une zone à un moment donné ?
les deux points doivent être traités en même temps. Toutes ces hypothèses sont des hypotèses conjointes.
ISIS a déjà du mal à gérer des applications avec de nombreuses mailles spatiales et on peut à peine faire 10 ans de simulation sur de telles applications; Faire exploser le nb de pas de temps ne va pas améliorer la performance
c'est pour ça que avec une telle résolution l'objectif ne sera pas 1. de tout modéliser 2. d'avoir des durées de simulation aussi importantes Il se peut que dans certain cas, il ne soit possible que de faire de l'exploration d'hypothèses.
Plus généralement, doit-on vouloir tout faire avec ISIS ? au risque de faire moins bien que d'autres modèles ciblés sur des échelles et des représentations précises. Ne faudrait-il pas mieux avoir plusieurs modèles séparés (des "ISIS-FILS") chacun destiné à des utilisations différentes ? par ex. un code pour une approche réellement spatiale, un pour une approche à échelle temporelle fine si c'est vraiment pertinent / modèle de base ISIS, ce dont je ne suis pas convaincue,
on ne pourra dissocier les deux echelles (temporelle et spatiale). Le choix du pas de temps mensuel dans ISIS, impose aussi d'une certaine manière une résolution spatiale. Donc donner de la souplesse à l'utilisateur (averti!) permettra de tester différentes hypothèses sur le comportement de la population et des pêcheurs. La question d'avoir plusieurs ISIS ne devrait pas se poser car pour l'utilisateur non averti tout sera comme avant (resolution temporelle par defaut = mois). Mais pas de soucis, on rediscutera de tout ça avant le développement car aujourd'hui rien n'est fixé.
L'idée de ISIS était de faire un modèle complexe mais parcimonieux et surtout de ne pas dériver vers une usine à gaz, ce qui peut se produire à force de rajouter des possibilités au gré des besoins individuels. C'est tout le souci, auquel on a veillé dès le départ de proposer un outil qui a de la flexibilité, mais qui a aussi une colonne vertébrale et un objectif précis.
oui je suis entièrement d'accord avec toi. Mais qui peut le plus peut le moins. Il s'agit surtout de donner de la flexibilité à ceux qui maitrisent l'outil. C'est interessant de voir la diversité des niveaux de complexité entre les différentes applications (ultra precises (cf Pélagique GdG de Sigrid ou cohabitent des modèles spatiaux structurés en longueur et des modèles globaux, ou celle de Bastien avec une resolution spatiale très fine) ou moins fines (cf poissons plats Manche structurée en age et proche des modèles d'evaluation). Il y a toujours quelques déboires dans le processus de parametrisation mais au final tout le monde réussit à faire tourner son appli et même à faire des analyses de sensibilité ou d'incertitude!
Merci de vos remarques et compléments d'information
on en reparle à Lorient Bises Stephanie
Dominique
Le 06/12/2012 22:47, Benjamin POUSSIN a écrit :
Salut,
Voila une petite réflexion rapide sur le pas de temps dans Isis (il manque sûrement des choses, donc il faut compléter)
La demande initial est de pouvoir faire un pas de temps hebdomadaire.
Les problèmes à un changement de pas de temps ============================================= - tout ce qui est migration vérifie les choses par rapport au mois, il faudrait que dans l'objet Month, on puisse avoir en plus la notion de quart de mois (=1semaine). - Les résultats se font avec des matrices mensuelles, il faudrait qu'en fonction du pas de temps choisi cette dimension puisse varier. - les saisons sont définis par un interval de mois - des Rules et autres scripts utilisent le mois pour faire des choses.
Quelques pistes pour y arriver ==============================
1ère solution -------------
l'idée sera de pouvoir définir en paramétrage de simulation la division de l'année souhaitée. (1=année, 4=saison, 12=mois, 52=semaine, 365=jour)
- L'objet TimeStep prendrait donc cette valeur comme pas de temps pour la simulation - TimeStep pourrait retourner des objets Year et YearStep (division courante de l'année. Ex: si 4 division d'année, 3 retourne l'equivalent des 3 derniers mois de l'année. si 12 divisions d'annee, 11 retourne l'equivalent du mois de décembre, ...) - Il serait agréable que lors de la division de l'année, l'utilisateur puisse déterminé le nom qu'il souhaite donnée à chaque division (si division en 12 alors janvier, fevrier, ...) Des propositions par défaut serait données, exemple division par 6 alors on propose (janvier/fevrier, mars/avril, mai/juin, ...) - il faudrait conserver une compatibilite avec l'existant, donc par defaut le decoupage est mensuel et la method getMonth dans ce cas fonctionne.
2ème solution -------------
L'idée sera de basé la plus petite division à 1 jour (le plus pratique je pense, si on descend en dessous du jour ça va être compliqué)
On indique ensuite avec combien de jour, on souhaite créer le pas de temps. 7=semaine, 30=mois, 90=trimestre, 360=année, 720=2 ans, ...
et combien de pas de temps à une rotation (équivalent d'une année avec les mois), ceci est nécessaire pour la création des saisons. Par exemple si on a un pas de temps de 30 jours, on peut indique qu'on utilise 12 pas de temps pour définir une année. Mais on peut vouloir travailler avec des saisons bi-annuelle, dans ce cas, on pourrait indiquer qu'un rotation prend 24 pas de temps.
- L'objet TimeStep prendrait donc cette valeur comme pas de temps comme incrément pour passer au pas de temps suivant pour la simulation - TimeStep pourrait retourner des objets Year(=360), Month=(30), Week=(7), Day=(1) quelque soit le le pas de temps choisi (toujours un multiple de jour) - La compatibilite avec l'existant est automatique si le pas est fixé a 30 et la rotation a 12 pas pour une année - il faut une méthode pour retourner le pas de temps courant dans la rotation choisi (0, 1, 2, ...) (step % stepByRotation). Ceci est nécessaire si on choisi un pas de temps différent de year, month, week, day. - je pense qu'il ne faut pas tenir compte des mois de 28, 29, 31 jours (beaucoup de complexite pour peu de plus value) - il faudra une option (case a cochée) dans le rendu des résulats pour indiquer si l'on veut les résultats sous forme d'année ou de rotation. Peut-etre meme un champs texte qui permette de définir l'affichage souhaite (ou une combo editable avec des valeurs par défaut existant, mais l'utilisateur pourra lui meme redéfinir ce qu'il souhaite) Par exemple pour un pas de temps de 30, une rotation de 720. Pour représenter la division 1500 avec: - %day = 1500 - %step = 50 - %stepInRotation r-%rotation = 1 r-2 (on suppose que le premier step est 0) - %month année %year = février année 4
La question a se poser est garde-t-on 0 comme valeur de premier élément ou on fini par prendre 1 ?
Conclusion ==========
La deuxième solution me semble beaucoup plus évolutive, elle permet de faire des pas de temps supérieurs à l'année, et de choisir sa rotation (on est plus obligé de suivre l'année). Par contre cette solution ne permet pas de faire une simulation sur un pas de temps inférieure au jour (au contraire de la 1ère). Mais ce n'est pas totalement vrai, il suffit de dire que la division minimal de 1 n'est pas un jour mais 1 heure, que la rotation est sur 8640 (dans ce cas les methodes year, month, ... retournent n'importe quoi, mais ceci n'a que peut d'importance, car ne servent a rien a part a affiche de facon plus agréable le pas de temps courant)
Les changements a faire ======================= - TimeStep - PopulationSeasonInfoImpl - DefaultSimulator - verifier que les scripts utilise bien le nouveau TimeStep
--
Dominique PELLETIER
Responsable de projet /Senior scientist/
Biodiversité et Aires Marines Protégées
/Biodiversity and Marine Protected Areas/
/PAMPA project : //wwz.ifremer.fr/pampa/ <http://wwz.ifremer.fr/pampa/>/
/www.ifremer.fr/ncal <http://www.ifremer.fr/ncal>///
IFREMER BP 2059, 98846 Nouméa Cedex
Nouvelle-Calédonie
Tél. (687) 292557 / 285171
Fax. (687) 287857
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org <mailto:Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
-- ...................................................................... Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr <mailto:Stephanie.Mahevas@ifremer.fr>) IFREMER/EMH (Ecologie et Modèles pour l'Halieutique) Tel: (33) 2 40 37 41 81 Fax: (33) 2 40 37 40 75
o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \ ......................................................................
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org <mailto:Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
-- ...................................................................... Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr) IFREMER/EMH (Ecologie et Modèles pour l'Halieutique) Tel: (33) 2 40 37 41 81 Fax: (33) 2 40 37 40 75 o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \ ......................................................................
participants (4)
-
Benjamin POUSSIN -
Dominique PELLETIER -
Sigrid Lehuta -
Stephanie MAHEVAS