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: 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.

Michel Roch, revisé 17 Mars 1995