Formalisme de synchronisation de modele

Formalisme de synchronisation de modele

FORMALISME DE SYNCHRONISATION DE MODELES 

Les prototypes et les réflexions sur la simulation de la compétition pour les ressources nous ont fait réaliser la nécessité de nous pencher sur une architecture de simulation générique capable de simuler des systèmes complexes formés par le couplage de modèles, et de synchroniser les calculs pour rester aussi cohérent que possible. Cette architecture et le formalisme de modélisation associé sont exposés dans ce chapitre

Briques de base

Le formalisme de synchronisation utilise principalement deux sortes d’objets : les Modèles et les Caches. Les Modèles sont des composants de calcul, et les Caches sont des abstractions des données servant d’entrées et de sorties `a ces calculs. Les Modèles lisent donc leurs entrées dans des Caches, puis écrivent leurs sorties dans d’autres Caches. Les Caches mettent alors `a jour les données réelles de manière synchrone. Cette architecture basique est illustrée sur la figure 3.1. Nous utilisons dans toute la suite la convention d’écriture suivante : le terme Modèle employé avec une majuscule a le sens particulier qui est décrit dans ce chapitre, employé avec une minuscule il désigne le modèle au sens de représentation de la réalité, comme employé plus couramment par les scientifiques. Une de ses propriétés les plus remarquable et utile est que les données de la simulation sont stockées dans une structure totalement séparée des composants de calcul, qui est toujours maintenue dans un état cohérent (en admettant que la mise `a jour soit instantanée). Cette structure de données représente l’état de la simulation, et suffit `a démarrer ou `a reprendre une simulation. Non seulement cela permet des simulations plus stables, puisque les Modèles lisent toujours des données cohérentes, mais cela résoud aussi élégamment, en théorie, le problème de l’arrˆet et et de la reprise des simulations, ainsi que celui de la sauvegarde indispensable des résultats. Décrivons maintenant plus précisément les objets de base.
La structure des données de la simulation est dupliquée au sein des Caches, qui l’isolent des Modèles, ce qui assure une évolution synchrone. Les Modèles lisent leurs entrées dans les Caches, écrivent leurs sorties dans la structure dupliquée stockée dans les Caches. Ils transmettent aussi une information temporelle au Manager qui permet de fixer dynamiquement le pas de temps de la simulation. L’opération de mise `a jour recopie les données locales des Caches vers les données de simulation. C’est cette opération qui est réalisée de manière synchrone.

Caches

Les Caches servent d’interface vers les données réelles, et font évoluer ces données réelles en les mettant `a jour sur demande. Ils ont un lien vers les données réelles et une copie interne de ces données dans laquelle ils stockent temporairement les nouvelles valeurs, d’o`u la dénomination choisie. Liens avec les Modèles Les Caches communiquent avec les Modèles `a travers deux interfaces spécifiques aux comportements différents, qui préservent la synchronisation des données de simulation. Ces deux interfaces permettent aux Modèles de collecter dans la liste des données externes les valeurs des variables d’entrée et de transmettre leurs variables de sortie. La première interface est le Getter. Un Modèle peut, `a partir d’un lien vers un Getter, lire une valeur. Dans ce cas le Cache renvoie la valeur stockée dans la structure de données externe. La seconde interface est le Setter. Un Modèle peut utiliser cette interface pour spécifier la future valeur `a affecter `a la donnée externe. Le Cache copie cette valeur et la conserve jusqu’`a la prochaine mise `a jour. Comme le Getter est lié `a la structure de données externes directement alors que.

Briques de base 45

le Setter agit sur la copie interne située dans le Cache, il n’y a aucun risque que la valeur renvoyée par le Getter soit modifiée par un Modèle interagissant avec le Setter. En revanche, il est souhaitable qu’un seul Modèle puisse interagir avec un Setter donné, sans quoi la valeur en cache risque d’ˆetre écrasée. L’interface Getter n’impliquant aucune modification, plusieurs Modèles peuvent sans problème lire la valeur d’un mˆeme Getter. Mise `a jour La valeur associée au Cache peut ˆetre mise `a jour de plusieurs fa¸cons, suivant le type de la valeur et le système simulé. La fa¸con évidente de mettre `a jour est de copier la nouvelle valeur dans la structure de données externe. Cependant, dans certains cas, conserver deux exemplaire d’une donnée peut ˆetre un gaspillage de mémoire. En particulier, quand la donnée contient une grande quantité d’information (une image par exemple) mais n’est modifiée que sur une petite partie de ces informations, une autre stratégie peut ˆetre choisie : on peut créer le Cache comme un Getter du « gros » type de donnée, et comme un Setter du type de donnée « variation », qui contient juste les informations nécessaires `a la mise `a jour.
En plus d’apporter des bénéfices en terme d’occupation mémoire et de vitesse d’exécution (car les opérations de copie sont d’autant plus coˆuteuses que les informations `a copier sont nombreuses), ce choix peut ˆetre naturel pour certains modèles, qui par définition calculent la variation d’une donnée et pas une valeur. Cohérence Un Cache est dit dans un état cohérent lorsque la mise `a jour ne causerait pas de changement significatif dans la valeur de la donnée externe. Significatif peut ici prendre plusieurs sens, selon les intentions et le choix de modélisation pour le couplage des Modèles. On peut ˆetre très strict et poser que tout changement de valeur est significatif, ou encore poser un seuil en de¸c`a duquel on considère la variation comme négligeable. Cette définition est importante pour assurer la convergence du système dans certains
cas, en particulier ceux comportant des boucles de rétroaction.

Modeles

Les Modèles sont responsables de tous les calculs de simulation. Ils peuvent ˆetre pourvus d’un état interne qu’ils doivent faire évoluer. Entrées, Sorties, Etat ´ Un Modèle possède une liste d’entrées I, qui sont autant de liens vers des interfaces Getters. 46 3. Formalisme de synchronisation de modèles L’état d’un Modèle est un ensemble de données qui lui sont propres, et ne sont accessibles en écriture que depuis l’intérieur du Modèle. Ces données sont accessibles par des Caches, comme les entrées et les sorties, sauf que dans le cas de l’état le Modèle possède le Cache et pas juste des liens vers des Getters et des Setters. Ainsi, on respecte le principe de séparation des données et des calculs, l’état des Modèles étant stocké dans la structure de données externe. Cela est nécessaire car un Modèle pourrait éventuellement ne pas ˆetre persistant en mémoire, alors que son état devrait l’ˆetre. Un exemple de ce type sera détaillé dans la partie Certains Modèles n’ont pas besoin d’état, et dans ce cas l’architecture de simulation présentée ne leur impose rien de particulier. La présence ou non d’un état pour un Modèle n’affecte en rien les fonctions de calculs présentées ci-après. Calculs Un Modèle doit définir trois fonctions qui seront utilisées dans l’algorithme de simulation. La première est la fonction cumul :
o`u OT est une liste des sorties « transitoires ». Cette fonction permet au Modèle de réagir instantanément aux changements de ses entrées. Un exemple de Modèle purement transitoire serait un additionneur qui se contente de faire la somme de ses entrées. Un tel Modèle n’a pas de mémoire du passé, pas de notion d’écoulement du temps. Il existe bien sˆur des cas de Modèles utilisant les deux fonctions, comme on le verra dans les exemples aux chapitres 4 et 5. A part ces fonctions de calcul, les Modèles définissent une ` troisième fonction time, utilisée pour la synchronisation : Ici tn est la date la plus lointaine `a laquelle un appel `a la fonction cumul du Modèle doit avoir lieu. Ceci permet en particulier, pour les modèles faisant une intégration temporelle, de fixer une borne supérieure au pas de temps. Mais les Modèles peuvent aussi s’en servir pour générer des évènements, par exemple.

Hierarchies 

Exemple simple Nous allons donner ici un exemple simple de Modèle utilisant les trois fonctions vues précédement. Le but du Modèle est, `a partir de deux entrées A(t) et B(t), de fournir la valeur S = A On peut mˆeme imposer une borne sur la variation de e, par exemple si elle ne doit pas dépasser la valeur K on peut choisir plutˆot : Reste `a voir comment l’appel des fonctions des Modèles et des Caches est organisé pour aboutir `a une simulation du comportement du système. Ceci fait appel au concept de hiérarchie et est détaillé dans la section suivante.

Hiérarchies

La spécification des Modèles et des Caches donne la capacité de construire des Modèles hiérarchiques, c’est-`a-dire contenant un graphe de Modèles et de Caches.

Hierarchie generique

La structure d’un Modèle hiérarchique est assez simple `a comprendre. Un exemple est détaillé sur la figure 3.2. On a besoin de définir des Getters et Setters particuliers, qu’on appelle des Buffers, pour transmettre les entrées du Modèle aux sous-Modèles et pour recopier les sorties des sous-Modèles dans celle du Modèle. Ces objets ne sont Chacun des Modèles a aussi un état, S1 et S2 respectivement. Des buffers I1 et I2 permettent de lire les entrées, d’autres O1 et O2 permettent d’écrire des sorties. Des lignes pointillées relient les Caches vers les données de simulation, dont la structure est `a l’image de celle du Modèle. Anisi, Data0 est la donnée d’état de Model0, et est composée de Data1 et Data2, les données d’état des sous-Modèles, et de V1 et V2, les valeurs associées aux Caches couplant les sous-Modèles. pas des Caches, en ce sens qu’ils ne sont pas liés `a une structure de données externe. Ils servent purement d’intermédiaires de calcul et n’ont pas `a ˆetre synchronisés. C’est le Modèle qui est responsable de leur gestion et de leur utilisation. Un Modèle hiérarchique a un état qui est représentatif de la structure interne,
c’est-`a-dire des Modèles et Caches qu’il possède. Il est entièrement responsable de la synchronisation de tous ces objets ; le Manager global de la simulation n’y a pas accès. Le comportement d’un Modèle hiérarchique varie suivant la modélisation souhaitée. Il peut ˆetre un véritable sous-simulateur qui isole temporellement ses sous-Modèles du reste de la simulation (ce qui est une fa¸con possible d’obtenir un effet de multi-échelle temporel). Il peut au contraire ˆetre simplement une « coquille » isolant des blocs logiques, mais n’ajoutant pas lui-mˆeme de comportements. Deux exemples d’utilisation de hiérarchies sont détaillés dans la suite, pour le management de la simulation d’abord, puis pour certaines variantes de spatialisation.

Table des matières

TABLE DES MATIERES
Remerciements
1. Contexte, enjeux et problematiques 
1.1 Contexte
2. Prototypes de simulateur 
2.1 Premier prototype de « paysage fonctionnel »
3. Formalisme de synchronisation de modele
4. Modèles pour les ressources 
5. GreenLab continu 
6. Illustrations et exemples
7. Conclusion et perspectives 
Calibration
Fonctionnement
Visualisation
Annexe 113
A. Programmation littéraire
A.1 Blocs et fragments
A.2 Fichier généré
A.3 Références croisées
B. Pseudocode complet de la fonction de synchronisation
Liste des figures
Bibliographie

Télécharger le rapport complet