Voici comment utiliser concrètement la localisation de z0 dans T-UGOm.
L’utilisateur peut créer des zones géographiques dans lesquelles il fixera la valeur du cœfficient de rugosité (z0). Pour ce faire, il faut fournir deux fichiers.
Le premier fichier doit contenir un descriptif de chacune des zones géographiques dans lesquelles on veut prescrire z0. Cette description se fait sous la forme de polygones. Les polygones doivent être enregistrés sous le même format que les maillages qu’utilise T-UGOm (« nei »). La figure A.6 donne un exemple d’ensemble de polygones.
Le second fichier est un simple fichier ASCII. Il doit contenir un ensemble de points de références pour le cœfficient de rugosité. Sur chaque ligne, il faut indiquer d’abord la longitude, ensuite la latitude et enfin la valeur du cœfficient de frottement en ce point. Voici un exemple de fichier de références :
Algorithme A.12 Détermine la valeur de z0 dans chacune des zones
Entrées : S l’ensemble des zones définies par des polygones, v l’ensemble des sommets de références et vz0 l’ensemble des valeurs de z0 qui leur sont associés
Sorties : la valeur de z0 est fixée pour tout les polygones n ←nombre de sommets dans v
p est un polygone
pour tout q ∈ P faire
fixer la valeur de z0 dans q à la valeur par défaut
fin pour
pour i variant de 1 à n par pas de 1 faire pour tout q ∈ S faire
si v(i) ∈ q alors
p ← q
fin si fin pour
fixer la valeur de z0 dans p à vz0 (i)
fin pour
-50.514553 3.4096332 0.009 -49.456573 3.1142113 0.007 -49.769367 2.5785582 0.02 -49.401375 2.393792 0.01 -48.729786 1.2107956 0.02 -49.65897 0.9796652 0.05
Les valeurs de z0 dans les polygones auxquels appartiennent chacun des points de références seront celles qui leurs sont associées.
Pour utiliser cette fonctionnalité, dans l’interface graphique de configuration du modèle, dans l’onglet « dissipation » il faut sélectionner, pour le champ « bottom_friction_type », le type « KARMAN ». Toujours dans cet onglet, dans le champ « rugosity_polygons », il faut entrer le chemin d’accès au fichier contenant la descrip- tion des polygones et, dans le champ « rugosity_values », le chemin d’accès au fichier contenant les points de référence pour la valeur du cœfficient de frottement de fond. Les points du maillage situés en dehors de tout polygone ou dans des polygones n’ayant pas de point de référence associé se verront attribuer comme valeur pour z0la valeur contenue dans le champ « karman_rugosity ». La figure A.7 donne un exemple de configuration.
Figure A.7 – Configuration de T-UGOm
Si l’utilisateur préfère ne pas avoir recourt à l’interface graphique de T-UGOm, dans le fichier de configuration, dans la section « dissipation », il lui faut renseigner les
champs « bottom_friction_type », « rugosity_polygons » et « rugosity_values » de la même manière qu’indiqué ci-dessus au niveau de l’interface graphique. Le champ « karman_rugosity » servira de valeur par défaut.
A.4
Conclusion partielle
En nous basant sur la théorie de graphes, nous avons pu créer un algorithme permet- tant de discriminer des zones géographiques. Nous l’avons appliqué au cas particulier de la friction de fond, car il nous a permis de prendre en compte la variabilité géographique de la friction de fond dans l’estuaire de l’Amazone (voir chapitre 3).
Notes d’implémentation
Une grande partie de cette thèse a consisté en l’implémentation informatique de méthodes numériques et d’algorithmes. Cet annexe donne quelques éléments pratiques concernant les choix d’implémentations et la structure du code.
Sommaire
B.1 Généralités . . . 165 B.2 Gestion des erreurs . . . 167 B.3 Cœfficient logarithmique . . . 168 B.4 Cartes de rugosités . . . 169
B.1
Généralités
Autant que possible, les développements de cette thèse ont été effectués selon une approche orientée objets et fonctionnelle. L’approche orientée objets est bien supportée par C++, mais il en supporte également d’autres. À l’inverse, pour utiliser les éléments avancés de l’approche fonctionnelle, par exemple les fonctions de l’ordre supérieur, il faut avoir recours à la bibliothèque standard (en-tête « <functional> »), voire à une biblio- thèque tierce telle que Boost1. Cependant, les éléments de programmation fonctionnelle utiles pour les développements effectués dans le cadre de cette thèse sont la récursivité et la composition de fonctions, tous deux parfaitement supportés de base par C++.
Également, il est préférable d’éviter de faire du C compilé par un compilateur C++. En effet, cela entraîne à passer à côté de certains éléments clefs du C++ et, surtout, à produire souvent un code moins efficace. De même, C++ considère la déclaration de variables comme une instruction, ce qui permet d’initialiser les variables en même temps que leur déclaration, donc d’éviter d’avoir des variables sans valeur significatives, source de bogues difficilement détectables. De plus, venant s’insérer dans un code de grande taille sur lequel plusieurs programmeurs ont travaillé, l’utilisation de noms de variables déjà utilisés par ailleurs est inéluctable. La possibilité, induite par le fait de considérer la déclaration comme une instruction, de déclarer en n’importe quel point du code les noms de variables permet d’en réduire la portée et donc de minimiser les risques de collision de noms. Réduire la portée des variables permet également d’éviter d’avoir des variables non significatives et cependant utilisables dans le code, également source d’erreurs complexes. C’est également pour ces raisons que les espaces de nommage (« namespace ») ont été utilisés.
Enfin, il est préférable de bannir les variables globales (le passage de variables par références permet de manière simple et efficace d’en supprimer toute utilité), la gestion de la mémoire de type C (« malloc » et « free ») et les conversions de type C, sources de beaucoup trop d’erreurs problématiques. À l’inverse, il ne faut pas utiliser à faire une utilisation massive la bibliothèque standard, qui nécessite certes un apprentissage, mais qui est efficace et qui propose de nombreuses fonctionnalités utiles, ce qui permet de gagner du temps de développement, de limiter le nombre de bogue et d’obtenir un code performant.
Le choix des noms est délicat, tout particulièrement en C++, qui peut être très bavard et, si des noms de variables peu explicites nuisent à la lecture, c’est aussi le cas des noms trop longs. Dans les codes produits pendant cette thèse, les noms de type, de classe ou d’espace de nommage commencent par une majuscule, les instances (les variables) commençant par une minuscule. Également, les noms de variables sont autant que possible les mêmes dans le code que dans les algorithmes et les traitements théoriques. Le projet impliquant des développeurs de divers pays, l’ensemble du code source est en anglais.
Tous les en-têtes sont protégés de la façon classique :
#i f n d e f NOM_FICHIER_SOURCE 1. http://www.boost.org/
#define NOM_FICHIER_SOURCE
/∗ I c i l e code source ∗/
#endif // #i f n d e f NOM_FICHIER_SOURCE
Dès l’or, l’en-tête peut être inclut dans n’importe quel fichier sans le moindre risque de définition redondante. De plus, les fichiers sources incluent tous les en-têtes qui leurs correspondent, afin d’être sûr que les prototypes sont bons. C’est la technique employée, entre autre, dans la bibliothèque standard.
Une grande partie du code réalisé pendant cette thèse est générique, c’est-à-dire qu’il ne porte pas sur un type particulier (utilisation du mot clef « template »). Le code ad hoc est créé par le compilateur en fonction des appels rencontrés. Dans certains cas, il peut y avoir des conflits, car différentes unités de compilations peuvent créer la même spécialisation du code. Le mot clef « static » permet d’éviter ce problème, en indiquant que le code est spécifique à son unité de compilation.
On trouvera dans le fichier « constants.h » l’ensemble des constantes utilisées dans le code.
Les spécificités de C ont imposé une organisation du code où une unité de compilation est décomposée en deux fichiers, un en-tête comportant les prototypes des procédures et fonctions et un fichier source contenant le corps de ces fonctions. Il s’agit d’une or- ganisation assez rigide, qui peut ne pas refléter la structure interne d’un programme. L’introduction du code générique dans C++ pousse à rassembler une grande partie des procédures et fonctions dans les en-têtes et à repenser l’organisation des sources d’un programme pour en refléter la logique interne. L’organisation du code produit pendant cette thèse est entre ces deux modèles.
Enfin, pour faciliter la compréhension du code, nous avons recourt au logiciel de documentation automatique Doxygen2.
Dans le cas des automates produits pendant cette thèse, la documentation se trouve à chaque fois dans le répertoire « doc », au format HTML (sous-répertoire « html »), PDF (sous-répertoire « latex ») et man page (sous-répertoire « man »). Pour générer la documentation au format PDF, une fois dans le sous-répertoire « latex », exécuter la commande « make ». La construction des automates se fait à l’aide de l’outil Scons3. À chaque fois, le fichier « README » dans le répertoire racine donne la méthode pour compiler le code.
On trouvera l’ensemble des fonctionnalités de C++, une description complète de la bibliothèque standard ainsi que des considérations sur les choix d’implémentations dans [Stroustrup, 2003].
2. http://www.stack.nl/~dimitri/doxygen/ 3. http://www.scons.org/