Assistance au calage de modèles numériques en hydraulique ... - TEL

CHAPITRE 5 IMPLÉMENTATION D’UN SYSTÈME OPÉRATIONNELÉvolution du langage YAKLComme évoqué précédemment, les besoins en modélisation ont nécessité une évolutiondu langage YAKL au travers de deux extensions principales :– l’ajout d’opérateurs ✭ locaux ✮ (Local Operator) a permis de représenter des tâchesterminales semblables à des opérateurs primitifs, mais au contenu entièrementheuristique. Ce type d’opérateur a ainsi permis de représenter des activitésnon décomposables qui ne constituent pas une encapsulation de l’exécution d’unprogramme quelconque, comme par exemple la SélectionDUnEvénement ;– la prise en compte de collections d’éléments a quant à elle permis de représenter lesdifférents jeux de données, de paramètres et autres, présents dans notre modélisation.L’exemple de l’utilisation de ces collections pour définir un hydrogrammeest donné sur la figure 5.8. Cette notion de collection est primordiale dans lecadre du calage, puisqu’un grand nombre d’objets utilisés sont présents sous cetteforme : données de référence, paramètres, etc.Structure de la base de connaissances et de la base de faitsComme vu dans la section 5.2.2 (p. 130), la constitution d’un système à base deconnaissances bâti autour du moteur PEGASE+ nécessite d’une part une base de connaissancesregroupant des fichiers textes écrits dans la syntaxe YAKL – selon les principes detraduction énoncés au-dessus – et d’autre part une base de faits, regroupant elle aussides fichiers écrits dans la syntaxe YAKL, et formalisant les connaissances spécifiques au(x)système(s) étudié(s). La figure 5.10 présente la structure de la base de connaissances dusystème CARMA-1, et la figure 5.11 présente la structure actuelle de la base de faits dece système.Un point important est à noter dans la structure de la base de connaissances : nousnous sommes focalisés sur la spécialisation des connaissances pour l’hydraulique et nousavons de fait immédiatement transposé les classes et activités génériques dans le domainede l’hydraulique. Quelques exemples permettent de prendre conscience de cette particularité: aucun opérateur ne représente la tâche générique – c’est-à-dire indépendantedu domaine – d’initialisation des paramètres. Un opérateur portant ce nom représentecette tâche directement dans le domaine de l’hydraulique fluviale (voir la figure 5.9).De la même façon, aucun type d’argument ne représente la classe générique modèle numérique.Un type d’argument portant ce nom représente en fait le concept de modèlenumérique en hydraulique fluviale. On ne peut donc pas dériver simplement cette basede connaissances dans un autre domaine.Cette particularité de la base de connaissances trouve son origine dans deux pointsdifférents. D’une part, des problèmes techniques se posent dans la gestion des typeset des sous-types. La spécialisation explicite dans la base de connaissances de tâchesgénériques nécessiterait ainsi la mise en place d’opérateurs d’interopérabilité tels queceux décrits dans le chapitre précédent (section 4.5.4, p. 115) pour passer du niveaudes connaissances hydrauliques au niveau des connaissances spécifiques au code MAGE,c’est-à-dire pour passer des objets du domaine aux fichiers utilisés par le code. D’autrepart, la base de connaissances s’est construite au fur et à mesure de nos travaux etl’identification d’un niveau générique de connaissances ne s’est pas imposée d’emblée.La lourdeur d’une implémentation systématique a posteriori d’opérateurs d’interopérabilitéentre le niveau ✭ générique ✮ et le niveau ✭ hydraulique ✮ nous a conduit à cette135