| 9 | | == Utlisation d'ORCHIDEE pour l'assimilation == |
| 10 | | |
| 11 | | == 1. Contexte == |
| 12 | | |
| 13 | | Pour l'assimiltion des données avec le modèle ORCHIDEE (e.g., carbone, flux de surface, etc..), le différentiateur automatique TAF est utilisé. |
| 14 | | TAF ne permettant pas la dérivation des sources de la version standard d'ORCHIDEE, un travail préalable important a été effectué. Ce travail permet de rendre le |
| 15 | | code ORCHIDEE compatible à TAF. En effet, pour TAF, un modèle (ici ORCHIDEE) doit lui être passé comme une fonction/subroutine ayant pour arguments d'entrée |
| 16 | | le nombre de paramètres pour lesquels on cherche à calculer les sensibilités (on appelera par la suite les paramètres à optimiser), le vecteur décrivant les valeurs de ces paramètres et en |
| 17 | | sortie la fonction coût calculée sur les variables auxquelles dépendent ces paramètres. Afin donc de rendre ORCHIDEE compatible pour TAF et aussi de minimiser |
| 18 | | ces développements lors de nouvelles mises à jour d'ORCHIDEE, nous avons: |
| 19 | | - crée de nouveaux drivers/modules qui permetlent de gérer les paramètres |
| 20 | | - mis au format les subroutines/fonctions d'ORCHIDEE standard pour TAF de façon automatique à partir d'un script shell. |
| 21 | | |
| 22 | | |
| 23 | | L'objectif de ce document est de lister dans un premier temps (point 2 ci-après) les actions qu'un utilisateur aura à effectuer pour mettre au format une version d'ORCHIDEE pour TAF, autrement dit pour |
| 24 | | la génération des codes dérivés (i.e., tangent linéaire et adjoint) pour l'assimilation. Ensuite, nous décrivons en détails les nouveaux drivers/modules |
| 25 | | développés ainsi que les différentes étapes pour la mise au format automatique du code ORCHIDEE standard respectivelment aux points 3 et 4. |
| 26 | | Enfin, nos questions et réflexions pour une amélioration de cette procédure de la mise en compatibilité du code ORCHIDEE pour TAF sont présentées au point 5. |
| 27 | | |
| 28 | | |
| 29 | | |
| 30 | | == 2. Actions pour la mise au format d'ORCHIDEE pour l'assimilation == |
| 31 | | |
| 32 | | |
| 33 | | == ''2.1: Note importante'' == |
| 34 | | Pour la mise au format d'ORCHIDEE pour TAF, les modules d'initialisation/allocation dans les répertoires sechiba (i.e., sechiba_init_alloc.f90) et stomate (stomate_init_alloc.f90) d'ORCHIDEE sont automatiquement générés. |
| 35 | | La création automatique de ces deux modules permet de considérer aisément toutes mises à jour d'ORCHIDEE pour l'assimilation sans un travail supplémentaire important. Pour la création de ces modules d'initialisation/alloctaion, |
| 36 | | nous avons mis dans chaque module dans ces répertoires après la commande CONTAINS, la liste des subroutines/fonctions qui ont un lien avec les fichiers d'initislisation. |
| 37 | | La nomemclature adoptée est donnée ci-après pour le cas de la subroutine routing.f90 dans ORCHIDEE/src_sechiba: |
| 38 | | {{{ |
| 39 | | ! List of subroutines for initialization : |
| 40 | | !- routing_init |
| 41 | | !- routing_clear |
| 42 | | !- routing_diagnostic_p |
| 43 | | !- routing_diagnostic |
| 44 | | !- routing_basins_p |
| 45 | | !- routing_basins |
| 46 | | !- routing_getgrid |
| 47 | | !- routing_sortcoord |
| 48 | | !- routing_findbasins |
| 49 | | !- routing_simplify |
| 50 | | !- routing_cutbasin |
| 51 | | !- routing_hierarchy |
| 52 | | !- routing_findrout |
| 53 | | !- routing_globalize |
| 54 | | !- routing_linkup |
| 55 | | !- routing_fetch |
| 56 | | !- routing_truncate |
| 57 | | !- routing_killbas |
| 58 | | !- routing_names |
| 59 | | !- routing_irrigmap |
| 60 | | }}} |
| 61 | | |
| 62 | | Il faut noter que désormais les tags/trunk d'ORCHIDEE comprennent déjà cette liste. Ainsi, s'il y a des ajouts de subroutines/fonctions dans de nouveaux modules d'ORCHIDEE qui ont un lien |
| 63 | | avec les modules d'initialisation/allocation, il faut les ajouter à liste existante ou créer cette liste dans les nouveaux modules concernés. |
| 64 | | |
| 65 | | |
| 66 | | |
| 67 | | == '' 2.2: Mise au format d'ORCHIDEE pour TAF et/ou exécution des codes obtenus '' == |
| 68 | | L'utilsateur doit exécuter les commandes décrites dans les 3 étapes suivantes pour avoir un code mis au format pour l'assimilation. |
| 69 | | |
| 70 | | === Etape 1 : Chargement des routines d’ORCHIDEE/IOIPSL/TAF pertinents pour l’optimisation === |
| 71 | | |
| 72 | | - lancer la commande model dans le répertoire util pour le code ORCHIDEE que vous souhaitez utiliser pour l'assimilation. On note $model-name cette configuration (Tapez model -h pour avoir la liste |
| 73 | | des modèles disponibles). Lancer donc: |
| 74 | | |
| 75 | | {{{ |
| 76 | | util> model -h $model-name |
| 77 | | }}} |
| 78 | | - Récupérer le tags d'IOIPSL que vous souhaitez |
| 79 | | - Récupérer le tags/trunk d'ORCHIDEE que vous souhaitez |
| 80 | | - Récupèrer éventuellement un tag/trunk d'ORCHIDEE_OL. Seul le fichier weather.f90 sera utilisé. |
| 81 | | - Déplacer le fichier weather.f90 dans le répertoire ASSIMILATION (EK: A faire automatiquement par makeorchidee_fcm ???) |
| 82 | | - Mettre le répertoire NETCDF contenant les fichiers NetCDF dont TAF a besoin dans le répertoire ASSIMILATION (EK: comment faire pour avoir ce répertoire pour tout le monde !!!!) |
| 83 | | |
| 84 | | |
| 85 | | === Etape 2: Mise au format du tag/trunk d'ORCHIDEE pour TAF === |
| 86 | | Deux principales taches sont effectuées par un script shell '''makeorchidee_fcm''': |
| 87 | | - la mise au format du tags/trunk d'ORCHIDEE pour TAF |
| 88 | | - le regroupement de tous les codes (i.e., ORCHIDEE, IOPSL), les nouveaux drivers/modules crées pour TAF et la subroutine weather.f90 dans ORCHIDEE_OL dans le répertoire ASSIMILATION |
| 89 | | |
| 90 | | Pour cela, il faut: |
| 91 | | - Aller dans le répertoire ORCHIDEE et exécuter: |
| 92 | | {{{ |
| 93 | | ORCHIDEE> makeorchidee_fcm -[d]optim |
| 94 | | }}} |
| 95 | | avec [d] pour debug.[[BR]] |
| 96 | | Le script makeorchidee_fcm qui est décrit plus en détails au point 4) : |
| 97 | | - Crée un répertoire de travail temporaire modeles_optim_temp à partir du répertoire ASSIMILATION |
| 98 | | - Met le répertoire ORCHIDEE dans modeles_optim_temp |
| 99 | | - Crée les fichiers d'initialisation/allocation dans ORCHIDEE/src_sechiba et ORCHIDEE/src_stomate |
| 100 | | - Met dans le répertoire ASSIMILATION toutes les sources de tous les répertoires d'ORCHIDEE dans modeles_optim_temp |
| 101 | | - Met dans le répertoire ASSIMILATION toutes les sources du répertoire IOPSL |
| 102 | | |
| 103 | | |
| 104 | | === Etape 3 : Application de TAF pour la dérivation des codes === |
| 105 | | Toutes les sources des codes pour l'assimilation sont désormais dans le répertoire ASSIMILATION. |
| 106 | | Se placer dans le répertoire ASSIMILATION pour effectuer la différentiation souhaitée.On note tangent linéaire (TL), tangent linéaire vectoriel (VTL), et adjoint (AD). Assurez-vous que vous avez le droit d'exécuter le script staf de TAF pertinent pour la différentiation. |
| 107 | | Dans le cas échéant, contacter la personne en charge du code pour l'assimilation pour faire le nécessaire. |
| 108 | | Le Makefile dans le répertoire ASSIMILATION permet d'effectuer ces actions ci-dessous (pour détails, l'éditer): |
| 109 | | - Si vous souhaitez avoir juste les codes dérivés par TAF pour: |
| 110 | | - le tangent linéaire TL dont les sources portent l'extension _tl.f90, lancer: |
| 111 | | {{{ |
| 112 | | gmake ctl |
| 113 | | }}} |
| 114 | | - le tangent vectoriel VTL dont les sources portent l'extension _vtl.f90, lancer: |
| 115 | | {{{ |
| 116 | | gmake cvtl |
| 117 | | }}} |
| 118 | | - l'adjoint AD dont les sources portent l'extension _ad.f90, lancer : |
| 119 | | {{{ |
| 120 | | gmake cadj (n'existe pas encore!!!) |
| 121 | | }}} |
| 122 | | Les codes dérivés sont mis dans le répertoire spécifique relatif à la différentiation que vous souhaitez faire: |
| 123 | | - TANGEANT pour les codes TL avec extension _tl.f90 |
| 124 | | - TANGEANT_VTL pour les cdoes VTL avec extension _vtl.f90 |
| 125 | | - ADJOINT pour les codes AD avec extension _ad.f90 |
| 126 | | |
| 127 | | |
| 128 | | - Si voulez compiler les codes d'ORCHIDEE mis au format TAF en mode direct (i.e., l'exécutable doit donner les mêmes résultats que le code ORCHIDEE standard), lancer: |
| 129 | | {{{ |
| 130 | | gmake |
| 131 | | }}} |
| 132 | | L'exécutable s'appelle orchidee_tl et se trouve dans le répertoire bin |
| 133 | | |
| 134 | | |
| 135 | | - Si vous souhaitez générer à la fois les codes dérivés par TAF et/ou les compiler pour: |
| 136 | | - le tangeant linéaire TL (exécutable orchidee_tl mis dans le répertoire bin et les codes dérivés sont (ou seront mis) dans TANGEANT)), lancer: |
| 137 | | {{{ |
| 138 | | gmake tl |
| 139 | | }}} |
| 140 | | - le tangent vectoriel VTL (exécutable orchidee_vtl dans le répertoire bin et les codes dérivés sont (ou seront mis dans TANGEANT_VTL)), lancer: |
| 141 | | {{{ |
| 142 | | gmake vtl |
| 143 | | }}} |
| 144 | | - l'adjoint AD (exécutable orchidee_adj !!! dans le répertoire bin), lancer: |
| 145 | | {{{ |
| 146 | | gmake adj ( n'existe pas encore !!!) |
| 147 | | }}} |
| 148 | | |
| 149 | | Pour plus détails, voir le Makefile dans le répertoire ASSIMILATION |
| 150 | | |
| 151 | | |
| 152 | | |
| 153 | | == 3. Description des nouveaux drivers/modules pertinents pour la dérivation du code d'ORICHIDEE par TAF et son exécution == |
| 154 | | |
| 155 | | Le logiciel TAF n’est pas capable de générer les codes dérivés d’ORCHIDEE sans une mise au format du code ORCHIDEE au préalable. Comme mentionné au poin 1., il faut passer |
| 156 | | à TAF une subroutine/fonction appelée e.g., model(n,x,f) avec n et x les arguments d'entrée et f étant l'argurment de sortie. On note: |
| 157 | | n, le nombre de paramètres pour lesquels on veut calculer les sensibilités, x, le vecteur décrivant les valeurs des paramètres et f, la fonction coût construite sur les variables |
| 158 | | du modèle auxquelles dépendent ces paramètres. |
| 159 | | |
| 160 | | Pour ORCHIDEE, nous avons développé le modèle model(n,x,f) à passer à TAF en se basant sur le programme principal d'ORCHIDEE dim2_driver.f90 et qui s'appelle: |
| 161 | | {{{ |
| 162 | | model.f90 (EK: A changer de nom ou OK??? ) |
| 163 | | }}} |
| 164 | | La subroutine model.f90 permet d'effectuer grosso modo les opérations suivantes: |
| 165 | | - Allocation et/ou initialisation de la plupart des variables SAVE d'ORCHIDEE à partir du module: |
| 166 | | {{{ |
| 167 | | init_model.f90 ( A voir si on modifie ce nom !!) |
| 168 | | }}} |
| 169 | | - Simulation d'ORCHIDEE en bouclant sur le temps par appel à: |
| 170 | | {{{ |
| 171 | | intersurf_main_2D du module intersurf.f90 |
| 172 | | }}} |
| 173 | | - Calcul de la fonction coût à la fin de la boucle de temps à partir du module: |
| 174 | | {{{ |
| 175 | | mo_cost.f90 |
| 176 | | }}} |
| 177 | | |
| 178 | | La subroutine model.f90 que l'on doit passer à TAF doit avoir au moins en entrée n le nombre de paramètres à optimiser et leurs valeurs |
| 179 | | mises dans un vecteur x. Le code ORCHIDEE dans sa forme standard n'est pas conçue de cette façon. En effet, les paramètres sont utilisés en dur dans |
| 180 | | les différéntes subroutines/fonctions du modèle. Nous avons donc crée de nouveaux modules qui permettent d'avoir des informations sur les paramètres nécessaires |
| 181 | | à fournir à model.f90. Ces modules qui sont décrits ci-après et qui sont mis dans le répertoire ASSIMILATION, permettent: |
| 182 | | - d'avoir des informations sur le dimensionnement de la simulation du modèle ORCHIDEE, i.e., dimensions temporelle et spatiale |
| 183 | | - d'avoir des informations sur le nombre de paramètres d'ORCHIDEE à optimiser |
| 184 | | - de mettre les valeurs des paramètres d'ORCHIDEE avec leurs noms spécifiques dans un vecteur |
| 185 | | - de remettre les valeurs des paramètres mis dans le vecteur aux noms des paramètres tels que décrits dans ORCHIDEE |
| 186 | | |
| 187 | | Les modules relatifs à ces opérations ci-dessus sont décrites aux points a-c. D'autres modules qui sont plus spécifiques soit pour TAF ou pour |
| 188 | | la compilation du code mis au format TAF sont détaillés au point d. Il faut également noter que certains de ces modules ont été développés par François Delage et Cedric Bacour (i.e., *_optim.f90) |
| 189 | | |
| 190 | | |
| 191 | | |
| 192 | | a) Informations sur le dimensionnement de la simulation d'ORCHIDEE |
| 193 | | |
| 194 | | Nous avons créé un nouveau module basé sur le module readdim2.f90 d'ORCHIDEE standard. Ce nouveau module s'appelle: |
| 195 | | {{{ |
| 196 | | mo_process.f90 (nom sans doute à changer !!!) |
| 197 | | }}} |
| 198 | | |
| 199 | | |
| 200 | | b) Informations sur les paramètres d'ORCHIDEE à optimiser |
| 201 | | |
| 202 | | Les modules suivants ont été développés pour: |
| 203 | | - l'initialisation des constantes et des paramètres pour l'optimisation |
| 204 | | {{{ |
| 205 | | constantes_optim.f90 |
| 206 | | parameters_optim.f90 |
| 207 | | }}} |
| 208 | | - l'interfaçage des paramètres à optimiser avec le code d'ORCHIDEE |
| 209 | | {{{ |
| 210 | | interface_optim.f90 |
| 211 | | }}} |
| 212 | | |
| 213 | | c) Information sur le nombre de paramètres et la mise en vecteur des paramètres pour TAF/ORCHIDEE (vice/versa) |
| 214 | | |
| 215 | | Pour l'accès au nombre de paramètres, la mise en vecteur de leurs valeurs, nous avons développé le module suivant: |
| 216 | | {{{ |
| 217 | | paramtransfo.f90 |
| 218 | | }}} |
| 219 | | Ce module permet également de remettre les valeurs des paramètres du vecteur aux noms des paramètres dans ORCHIDEE. |
| 220 | | |
| 221 | | |
| 222 | | d) Autres modules pour l'exécution d'ORCHIDEE mis au format pour TAF [[BR]] |
| 223 | | Pour la construction des exécutables du code ORCHIDEE mis au format pour TAF en mode direct et/ou des codes dérivés (i.e., TL, VTL, AD), |
| 224 | | nous avons développé de nouveaux modules: |
| 225 | | |
| 226 | | - Appel des subroutines/fonctions pour les initialisations des paramètres (nombre et vecteur) par |
| 227 | | {{{ |
| 228 | | initparam.f90 |
| 229 | | }}} |
| 230 | | |
| 231 | | |
| 232 | | - Compilation des différents codes: |
| 233 | | - Code direct, i.e., ORCHIDEE standard mis au format pour TAF: |
| 234 | | {{{ |
| 235 | | direct.f90 |
| 236 | | }}} |
| 237 | | - Code tangeant linéaire (TL): |
| 238 | | {{{ |
| 239 | | tangeant.f90 |
| 240 | | }}} |
| 241 | | - Code tangent linéaire vectoriel (VTL): |
| 242 | | {{{ |
| 243 | | tangeant_vtl.f90 |
| 244 | | }}} |
| 245 | | - Code adjoint |
| 246 | | {{{ |
| 247 | | adjoint.f90 (N'existe pas encore !!!=) |
| 248 | | }}} |
| 249 | | |
| 250 | | |
| 251 | | == 4. Description de la mise en format automatique du code ORCHIDEE pour l'assimilation par le script makeorchidee_fcm == |
| 252 | | |
| 253 | | Dans le but de profiter des développements futurs d’ORCHIDEE pour l’assimilation des données, nous avons développé des outils de transformation (scripts shell) |
| 254 | | pour la mise au format automatique du code d’ORCHIDEE pour TAF. La démarche pour cette mise au format se fait en trois étapes suivantes et ces différentes |
| 255 | | étapes sont effectuées en une seule fois par l'utilisateur par le ancement du sccript makeorchidee_fcm dans le répertoire ORCHIDEE (voir point 2.2): |
| 256 | | {{{ |
| 257 | | ORCHIDEE> makeorchidee_fcm -[d]optim |
| 258 | | }}} |
| 259 | | Toutes les opérations effecutées par ce script sont détaillées en trois étapes: |
| 260 | | |
| 261 | | === Etape 1 : Chargement des routines d’ORCHIDEE/IOIPSL/TAF pertinents pour l’optimisation que l'on veut réaliser === |
| 262 | | - Crée un répertoire de travail temporaire modeles_optim_temp à partir du répertoire ASSIMILATION |
| 263 | | - Met le répertoire d’ORCHIDEE dans le répertoire modeles_optim_temp |
| 264 | | |
| 265 | | |
| 266 | | === Etape 2 : Préparation des routines d’ORCHIDEE pour la mise au format pour TAF === |
| 267 | | |
| 268 | | makeorchidee_fcm se place dans modeles_optim_temp: |
| 269 | | - configure le Makefile pour enlever les pré-compilations PARALLEL et ASSIMIL (EK: Pas clair si c'est fait ici !!) |
| 270 | | - Crée les modules d’allocation/initialisation dans les répertoires où existe un fichier init_alloc. Ce nouveau fichier s’appelle ${rep}_init_alloc.f90 (par exemple sechiba_init_alloc.f90) et la procédure pour sa création est décrite dans l'étape suivante 3 : |
| 271 | | |
| 272 | | |
| 273 | | === Etape 3 : Création des routines pour TAF === |
| 274 | | |
| 275 | | Boucler sur le/les fichiers sources de chaque répertoire deux fois avec deux scripts awk |
| 276 | | - script 1 : ASSIMILATION/TOOLS/variables.awk |
| 277 | | - Avant IMPLICIT NONE : |
| 278 | | - Garder les USE dans le fichier $rep_init_alloc ( => à voir ... ) |
| 279 | | - Entre IMPLICIT NONE et CONTAINS : |
| 280 | | - Garder les INTERFACE. Gestion particulière ? En effet, TAF n’arrive pas à les gérer proprement sans l’utilisation de directives. En particulier, la gestion des INTERFACE des codes IOIPSL se fait via le fichier taf_directives.f90 qui est inclus dans model.f90 et dans le Makefile dans ASSIMILATION |
| 281 | | - Couper les variables globales SAVE. Mettre ces variables dans le fichier $rep_init_alloc.Il faut noter que pour l’assimilation, toutes ces variables sont désormais PUBLIC. |
| 282 | | - Couper les variables SAVE locales (dans les subroutines/fonctions) dans les fichiers $rep_init_alloc du répertoire traité. |
| 283 | | - Mettre ces variables dans le fichier $rep_init_alloc. Aussi, toutes ces variables sont désormais PUBLIC. |
| 284 | | Attention à se conformer à la règle de programmation pour éviter la redondance !!!. (EK: Pour cela, on pourrait remplacer les variables locales "var" par $nommodule_nomfonction_var). En effet, on met des variables "var" locales à une fonction "nomfonction" depuis un module "nommodule" en SAVE global dans $rep_init_alloc. Le risque ici c'est d'avoir des noms $nommodule_nomfonction_var trop longs !!! |
| 285 | | - Ajouter CONTAINS à la suite dans le fichier $rep_init_alloc |
| 286 | | |
| 287 | | - script 2 : ASSIMILATION/TOOLS/subroutines.awk |
| 288 | | - Lire la phrase " List of subroutines for initialization :" » et construire un tableau init_functions qui lit chaque ligne commençant par "!-". Voir un exemple de cette liste pour routing.f90 au point 2.1. |
| 289 | | - Couper les fonctions init dans init_alloc pour inclusion dans $rep_init_alloc |
| 290 | | - Gérer/simplifier les appels du module d'optimisation depuis intersurf.f90 (A discuter ???) |
| 291 | | - Retravailler les parties driver/readdim2.f90 pour rendre plus rapide cette partie pour l'initialisation (EK ???) |
| 292 | | - Copier toutes les sources de modeles_optim_temp dans le répertoire ASSIMILATION |
| 293 | | - Supprimer modeles_optim_temp |
| 294 | | |
| 295 | | |
| 296 | | == 5. Questions et Réflexions == |
| 297 | | - Il faudra dans les tags/trunk ORCHIDEE : construire et maintenir de la liste des subroutines/fonctions d’initialisation par module (pas d'autres implications des développeurs "standard" |
| 298 | | pour conserver les optimisations dans les futures développements) |
| 299 | | |
| 300 | | |
| 301 | | - Gestion des « includes » des directives TAF: Il faut noter que cela se fait dans model.f90 et dans le Makefile du répertoire ASSIMILATION. Néanmoins, les directives TAF doivent être spécifiques à chaque version d'ORCHIDEE pour l’optimisation et aussi à la version de IOIPSL. Ce n'est pas simple de gérer automatiquement ces directives TAF parce qu'on n'a pas trouvé de façon claire les raisons pour lesquelles certaines variables SAVE ou fonctions/subroutines ne sont pas analysées par TAF. Pour l'instant, nous gérons ces directives à la main dans le fichier taf_directives.f90 et ceci en fonction des problèmes rencontrés lors de l'exécution des codes dérivés générés par TAF. On pourrait faire une gestion automatique en appliquant des directives à toutes les fonctions/subroutines dans le fichier taf_directives.f90 !!! A titre d'exemple, voici ci-après les directives pour le cas simple de la subroutine ymds2ju du module calendar.f90 de la librairie IOIPSL. Il faut noter que sans ces directives, TAF ne considère pas l'appel de la subroutine ymds2ju dans le code dérivé e.g., model_tl.f90. On note les numéros des arguments d'entrée de la subroutine dans la commande INPUT et dans OUTPUT ceux des arguments de sortie. Enfin, la commande REQUIRED permet de dire à TAF de considérer cette subroutine lors de la génération des codes dérivés. Après une analyse approfondie de ce cas, nous n'avons pas compris les raisons pour lesquelles TAF ne considère pas cette subroutine dans le code dérivé model_tl.f90. Pour plus de détails sur les directives TAF, il faut consulter la documentation d'utilisation du logiciel qui est fourni. |
| 302 | | {{{ |
| 303 | | !$TAF SUBROUTINE calendar::ymds2ju INPUT = 1,2,3,4 |
| 304 | | !$TAF SUBROUTINE calendar::ymds2ju OUTPUT = 5 |
| 305 | | !$TAF SUBROUTINE calendar::ymds2ju REQUIRED |
| 306 | | }}} |
| 307 | | |
| 308 | | - Gestion de l’interdépendance des USE: On considère actuellement tous les USE dans chaque modules/subroutines/fonctions. Dans la configuration actuelle, il y peut avoir une redondance des USE. En effet, un module appelant déjà un USE est appelé en USE avec les appels des USE qui sont dans ce module. A titre d'exemple, le module iopsl appelle en USE certains modules et souvent le module ioipsl est appelé en USE avec certains des modules de iopsl. Difficile à gérer automatiquement, mais cela peut être géré lors de la programmation !! |
| 309 | | |
| 310 | | - Gestion des INTERFACE: TAF n'arrive pas à les gérer donc on les gère à la main dans le fichier taf_directives.f90 ou on considère directement dans le code ORCHIDEE la subroutine/fonction qui est effectivement utilisée pour l'assimilation. A titre d'exemple, on a remplacé l'INTERFACE suivante: |
| 311 | | {{{ |
| 312 | | INTERFACE intersurf_main |
| 313 | | MODULE PROCEDURE intersurf_main_2d, intersurf_main_1d, intersurf_gathered, intersurf_gathered_2m |
| 314 | | END INTERFACE |
| 315 | | }}} |
| 316 | | par l'expression suivante ou la subroutine intersurf_main_2d qui est principalement utilisée dans model.f90 lors de l'assimilation est rendue PUBLIC: |
| 317 | | {{{ |
| 318 | | PUBLIC :: intersurf_main_2d, stom_define_history, intsurf_time, intsurf_restart,l_first_intersurf |
| 319 | | }}} |
| 320 | | |
| 321 | | |
| 322 | | - les sources NetCDF: TAF a besoin de certaines sources NEtCDF. On met ces sources dans le répertoire ASSIMILTION/NETCDF tel que décrit au point 2.2. Pour leurs utilisations par TAF, voir le Makefile dans le répertoire ASSIMILATION. Voici la liste de ces sources: |
| 323 | | {{{ |
| 324 | | netcdf_attributes.f90 |
| 325 | | netcdf_dims.f90 |
| 326 | | netcdf_expanded_modif.f90 |
| 327 | | netcdf.f90 |
| 328 | | netcdf_overloads.f90 |
| 329 | | netcdf_text_variables_modif.f90 |
| 330 | | netcdf_visibility.f90 |
| 331 | | netcdf_constants.f90 |
| 332 | | netcdf_expanded.f90 |
| 333 | | netcdf_externals.f90 |
| 334 | | netcdf_file.f90 |
| 335 | | netcdf_text_variables.f90 |
| 336 | | netcdf_variables.f90 |
| 337 | | typeSizes.f90 |
| 338 | | }}} |
| 339 | | Comment gérer ces sources NetCDF? Les commettre ?? |
| 340 | | |
| 341 | | - Gestion de la liste des modules. La faire dans le AA_make du répertoire ASSIMILATION ? |
| 342 | | - Conformité aux règles de programmation ??? |
| 343 | | - Unicité des variables dans les différents modules ??? |
| 344 | | |
| 345 | | |
| 346 | | |
| 347 | | == 6. Autres == |
| 348 | | Afin de pouvoir appeler model.f90 plusieurs fois dans une boucle FORTRAN et ceci dans la perspective d'une optimisation dans un environnement FORTRAN, des adapations on été faites dans les sources de IOIPSL. Ces adapations qui sont déjà dans le tags/trunk d'IOIPSL ont été principalement effectuées dans: |
| 349 | | les modules suivants: |
| 350 | | {{{ |
| 351 | | histcom.f90 |
| 352 | | flincom.f90 |
| 353 | | }}} |
| 354 | | |
| 355 | | Cela a permis de fermer les fichiers et de reinitialiser les variables liées à ces fichiers à la fin d'un appel de la subroutine model.f90. Ceci est obtenu par appel des subroutines histclo et flinclo à la fin de model.f90. Il faut noter que histclo et flinclo sont dans les modules histcom.f90 et flincom.f90, respectivement. |
| 356 | | Commentaires EK; Martial, n'hésite pas à y ajouter d'autres adaptations effectuées. |
| 357 | | |
| 358 | | [[BR]] |
| 359 | | [[BR]] |
| 360 | | |
| 361 | | |
| 362 | | |
| 363 | | |
| | 9 | Voir nouvelle Branches/Assimilation/Implementation |
