PRINCIPES GÉNÉRAUX: MODÈLE GEM
OBJET
Ce document énumère un ensemble de principes généraux
qui devraient être suivis lors de la construction du modèle
barocline GEF. D'autres documents allant dans plus de détails pourront
être rédigés au fur et à mesure des besoins
lors de l'élaboration du code.
EXPORTABILITÉ
Si on veut maintenir l'exportabilité, les extentions au fortran
standard ne peuvent être utilisées les énoncés
dans la version EXPORT. Les énoncés POINTER et la fonction
LOC font partie de ces extentions. Il en va de même de toutes les
fonctions reliées aux fichiers standards, à la gestion de
l'espace mémoire et à accès rapide, etc.
Cependant, si on centralise l'allocation de mémoire pour
le modèle dans un seul sous-programme et que l'on assure la distribution
d'espace de travail local par l'intermédiaire de quelques comdecks
ayant des fonctions bien spécifiques, on peut générer
une version statique qui soit exportable en fournissant une quantité
raisonnable d'effort.
Ce qu'il faut éviter est de répandre partout dans
le code des énoncés qui dépendent d'une famille restreinte
de machines. Si cela est nécessaire, cet énoncé devrait
être appelé à partir d'un sous-programme ou d'un comdeck
qui lui sera appelé partout dans le code. De cette façon,
il n'y aura qu'une seule intervention à faire pour générer
un code exportable plutôt qu'une multitude.
GESTION DE L'ESPACE DISQUE, XMU, INCORE, ETC.
Il est nécessaire de prendre des décisions à très
haut niveau sur la structure du modèle et sur la répartition
des champs entre la mémoire vive et l'espace à accès
rapide. Il existe deux stratégies qui résident aux deux extrêmes
en ce qui concerne cette répartition:
-
Un modèle qui est entièrement incore: cette approche a l'avantage
de la facilité de développement car tous les champs dont
on a besoin sont immédiatement disponibles. On n'a donc aucune gestion
d'espace à accès rapide à faire et on n'a pas à
se préoccuper des limitations de l'interface I/O. À l'exécution
un tel modèle est également très efficace. L'inconvénient
majeur est que l'on frappe rapidement la limite physique de la mémoire,
ce qui nous empêche de tourner des modèles à des résolutions
intéressantes.
-
Un modèle qui n'utilise la mémoire vive que comme accumulateur
pour les différents calculs, tous les champs dynamiques du modèle
aux différents niveaux temporels résident sur l'espace à
accès rapide (SSD, XMU, etc.). Cet accumulateur aurait pour taille
minimale l'équivalent de trois champs tridimensionnels (A = B +
C). L'avantage de cette approche est d'occuper un minimum d'espace en mémoire
et donc de pouvoir tourner des modèles à plus haute résolution.
Cependant cet avantage porte son propre inconvénient puisque si
le rapport de l'espace de mémoire vive à l'espace à
accès rapide n'est pas toujours très faible, on frappera
la limite de ce dernier alors que la mémoire vive ne serait pas
encore pleine. Il ne faudrait pas non plus sous estimer la complexité
de la gestion à bas niveau de ces deux espaces. Le codage serait
de beaucoup alourdi. Le passage de la boucle temporelle du modèle
barotrope à celle du modèle barocline ne pourrait se faire
d'une façon évolutive. On devrait refondre le calcul de beaucoup
d'algorithmes existants.
La solution qui a été retenue est ne ne prendre aucune décision
"dure" sur la répartition de la demande d'espace entre la mémoire
vive et la mémoire à accès rapide en utilisant une
nouveau progiciel qui s'occupe de gérer ces deux espaces d'une façon
intégrée. Il s'agit du Virtual Memory Maneger (VMM). C'est
la quantité de ressource mémoire demandée par l'utilisateur
qui déterme ce qui sera incore et ce qui sera sur disque. Un petit
modèle serait donc entièrement incore. Plus le modèle
est gros, plus il y a de champs dans l'espace à accès rapide.
Le gestionnaire de mémoire vive/disque fait cette répartition
automatiquement. Le style de codage que sous-tend l'utilisation d'un tel
progiciel en est une d'usage minimal de la mémoire vive.
De plus, tous les champs en mémoire devront être
dimensionnés (nis, njs, nks) dimensions de stockage pour éviter
les conflits de banque.
VARIABLES DYNAMIQUES DU MODÈLE (3D + 2D)
La règle de base qui pourrait être utilisée dans ce
domaine est que peu importe le nombre de variables, on voudra toujours
en ajouter d'autres. Par exemple, l'analyse du transport de différents
composés chimiques ne peut se faire que si on peut définir
un certain nombre de traceurs passifs. La gestion de la mémoire
vive et de l'espace à accès rapide se fait donc de telle
sorte qu'on puisse facilement ajouter des variables selon l'évolution
des besoins.
INTERFACE PHYSIQUE
Une décision avait été prise à l'effet que
le module de physique passerait des tendances à la dynamique. Un
projet de refonte de l'interface physique est en cours pour réaliser
cet objectif. On en tiendra donc compte lors de la construction du code.
Une modification à l'interface devra également refléter
le fait que l'on désire traiter l'énergie turbulente comme
une dérivée totale du côté dynamique, et compléter
les calculs physiques par la suite à l'intérieur du module
de physique.
CONSTANTES
Toutes les constantes, qu'elles soient de types universelles, physiques
ou utilisées dans les conversions d'unités sont initialisées
à partir d'un sous-programme fourni par RMNLIB de façon à
ce que tous utilisent les mêmes constantes, des programmes d'entrée,
au modèle, au programme de sortie, et également d'un modèle
à l'autre. Certaines constantes, tels [[pi]], e, etc., pourraient
être générées dynamiquement à la précision
de la machine porteuse par cet utilitaire. Ce sous-programme se nomme "constnt".
INITIALISATION
L'initialisation se fait à l'aide d'un appel à un seul sous-programme
à haut niveau, qui lui appelle le pas de temps du modèle.
Ce module d'initialisation pourra être appelé par l'analyse
variationnelle ou par le modèle lui-même au besoin. Cela implique
une grande modularité dans la construction des différents
éléments.
La technique d'initialisation utilisée est la technique
du filtre digital. On a choisi cette technique plutôt que l'initialisation
par modes normaux à cause de sa facilité d'implémentation
tout en ayant une performance équivalente pour éliminer les
oscillations gravitationnelles non physiques, avec paramétrages
actifs.
POSTPROCESSING
Le post-traitement conventionnellement fait à l'extérieur
du modèle sera rapatrié dans le modèle pour des raisons
de flexibilité et d'efficacité: présence des opérateurs
du modèle, etc.
Le module d'écriture sera centralisé pour assurer
l'exportabilité (write/fstecr) de façon à ne pas générer
de fichiers standards si requis.
Le module de post-traitement écrira directement sur la
grille de calcul (horizontale) du modèle et les utilitaires standards
de RPN (graphisme = sigma, interpolateurs = pgsm, xrec, etc.) seront adaptés
pour reconnaître cette grille. Cette solution est rentable à
long terme, dans le cadre d'une utilisation opérationnelle du modèle,
et pour une grande variété de contextes, un peu comme ce
fut le cas pour la grille du modèle EFR.
LIMITATION SUR LE NOMBRE DE NIVEAUX
Dans le cadre du développement du modèle, on n'empêchera
pas explicitement que NK soit égal à 1, comme par exemple
en dimensionnant un champ de travail à une dimension fixe sur NK
en faisant l'hypothèse que NK ne serait jamais plus petit qu'un
certain nombre. Il ne devrait donc y avoir aucune hypothèses cachées
lors de la construction du code. Cette action a permis d'obtenir, une version
barotrope du modèle simplement en fixant NK = 1. Ceci permet de
régler les problèmes de maintenance d'une version barotrope
séparée du modèle. Cette version barotrope de GEF
permettra par exemple de tourner des expériences avec un filtre
de Kalman, de faire des études des covariances d'erreur de prévision
ou encore pour des études de systèmes simulés d'observation.
Tout le travail qui sera fait pour le développement du linéaire
tangeant et du modèle adjoint dans la version barotrope du modèle
s'appliquera automatiquement à la version barocline.
POIDS TEMPORELS
On a codé le modèle barocline, en fonction d'une liste de
poids temporels disponibles d'une façon centralisée dans
un common. On a soigneusement évité de coder ces poids directement
dans le modèle à une valeur fixe. Lors de l'évolution
du schéme temporel et en fonction du type de décentrage temporel
que l'on désirera appliquer, ces poids seront appelés à
changer.
DOCUMENTATION
La documentation de tous les sous-programmes et de tous les comdecks du
modèle doit être en anglais. Tout nouveau code doit se conformer
à ce principe et la documentation des quelques morceaux de code
ancien qui ne respecte pas cette règle sera traduite à court
terme. La documentation de tout nouveau module devrait respecter les règles
énoncées dans le document "NORMES DE DOCUMENTATION RPN",
revision du 21 mai 1993. De plus, toute modification à un module
existant doit porter un numéro de revision portant le nom de son
auteur, la date et la nature de la modification. Le respect de ces règles
simples permettra l'extraction, la mise en forme et la génération
automatique d'une documentation à partir du code source FORTRAN.
NORMES DE NOMENCLATURE DES VARIABLES (DOCTOR2)
Le nouveau code devrait être développé en suivant une
norme de nomenclature lors du codage des variables de modèle. La
norme DOCTOR2 qui est une adaptation locale de la norme DOCTOR a été
choisie et doit être utilisée dans tout module écrit
pour le mdèle GEF.
FICHIER DE REPRISE
Le concept de fichier de reprise a évolué de la notion d'un
seul fichier distinct qui contient tout ce qui est nécessaire pour
repartir un modèle à un moment de l'intégration, et
qu'il faut construire selon une structure bien particulière, à
celle d'un ou d'un ensemble de fichiers utilisés par le modèle
durant le cours de son intégration, et qui à un point quelconque
de cette dernière peuvent être copiés ailleurs et permettre
au modèle de repartir de là où il était rendu.
Tous ces fichiers doivent être gérés par le Virtual
Memory Manager. De cette façon toute la difficulté de la
gestion du fichier de reprise est prise en charge par des modules de bibliothèque
à bas niveau. La responsabilité de l'usager se limite donc
à modifier le JCL du lanceur pour assurer le déclanchement
des tranches successives du modèle et de déplacer les fichiers
de controle du VMM si nécessaire.
PRÉREQUIS DE LIVRAISON D'UN ENSEMBLE DE MODIFICATIONS.
-
Tous les decks modifiés doivent porter un numéro de revision
indentifiant son auteur, et la nature de la modification.
-
Tous les nouveaux decks et comdecks doivent être documentés
selon la norme en vigueur dans le modèle.
-
Tous les modules doivent respecter la norme DOCTOR2.
-
Les modifications doivent avoir été validées sur le
serveur et sur la NEC a 32 et 64 bits.
-
On devra vérifier que les principales options du modèle fonctionnent
toujours (version barotrope, reprise, etc).
-
Si une modification requiert une modification au lanceur, un lanceur modifié
doit être fourni avec la livraison.
Michel Roch, revisé 17 Mars 1995