Assimilation of ORCHIDEE model

---

6/06/2012: Réunion de travail

Martial Mancip and Ernest Koffi

Utlisation d'ORCHIDEE pour l'assimilation

1. Contexte

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é. TAF ne permettant pas de générer les codes dérivés directement avec la version standard d'ORCHIDEE, un travail préalable important a été effectué afin de rendre le code ORCHIDEE compatible à TAF. En effet,le modèle (ici ORCHIDEE) doit être passé à TAF comme une fonction/subroutine ayant pour arguments d'entrée le nombre de paramètres pour lesquels on cherche les sensiilités (on appelera par la suite les paramètres à optimiser),le vecteur décrivant les valeurs de ces paramètres et en 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 surtout de minimiser ces développements lors de nouvelles mises à jour d'ORCHIDEE, nous avons effectué ce travail suivant qui consiste principalement en:

• la création de nouveaux drivers/modules qui permetlent de gérer les paramètres
• la mise au format automatique des subroutines/fonctions d'ORCHIDEE standard pour TAF via des scripts awk.

L'objectif de ce document est de lister dans un premier temps (point 2 ci-après) les actions à effectuer pour mettre au format une version d'ORCHIDEE pour TAF, autrement dit pour 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 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. 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.

2. Actions pour la mise au format d'ORCHIDEE pour l'assimilation

' ' 2.1: Note importante ' '
Pour la mise au format d'ORCHIDEE pour TAF, nous générons aussi automatiquement les modules d'initialisation/allocation dans les répertoires sechiba (i.e., sechiba_init_alloc.f90) et stomate (stomate_init_alloc.f90) d'ORCHIDEE. 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 cela, 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. La nomemclature adoptée est donnée ci-après pour le cas du la subroutine routing.f90:

! List of subroutines for initialization :
!- routing_init
!- routing_clear
!- routing_diagnostic_p
!- routing_diagnostic
!- routing_basins_p
!- routing_basins
!- routing_getgrid
!- routing_sortcoord
!- routing_findbasins
!- routing_simplify
!- routing_cutbasin
!- routing_hierarchy
!- routing_findrout
!- routing_globalize
!- routing_linkup
!- routing_fetch
!- routing_truncate
!- routing_killbas
!- routing_names
!- routing_irrigmap

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 on un lien avec les modules d'initialisation, il faut les ajouter à liste existante ou créer cette liste dans les nouveaux modules concernés.

2.2: Mise au format d'ORCHIDEE pour TAF et/ou exécution des codes obtenus
L'utilsateur doit exécuter les commandes suivantes décrites dans les 3 étapes suivantes pour avoir un code mis au format pour l'assimilation.

Etape 1 : Chargement des routines d’ORCHIDEE/IOIPSL/TAF pertinents pour l’optimisation

• lancer la commande model dans le répertoire util pour la configuration spécifique à l'ASSIMILATION que vous souhaitez réaliser. On note $assimil-name cette configuration (éditer le fichier mod.def uu préalable pour choisir le type d'optimisation)

Commentaires EK: A définir les différents types d'assimilation.... On met dans ce répertoire ASSIMILATION tous les nouveaux drivers/modules en plus de module weather.f90 de ORCHIDEE_OL???:

util> model -h [$assimil-sname]

• Récupérer le tags d'IOIPSL que vous souhaitez, i.e., $ioipsl-name

   util> model -h [$ioipsl-name] 
  

• Récupérer le tags d'ORCHIDEE que vous souhaitez, i.e., $model-name

  util> model -h [$model-name]
  

• Récupèrer un tag/trunk d’ORCHIDEE/ORCHIDEE_OL pertinente à l’optimisation qu’on veut réaliser (noté $model_ol-name). Seul le fichier weather.f90 sera utilisé

  util> model -h [$model_ol-name]
  

(Commentaires EK: A discuter car si on suppose que weather.f90 ne change pas, alors on n'aura pas besoin de faire ca. On mettrait weather.f90 avec les autres drivers/modules dans le repertoire ASSIMILATION)

• Déplacer les répertoires IOIPSL, ORCHIDEE et éventuellement le fichier weather.f90 dans le répertoire ASSIMILATION ( A vérifier avec Martial ce n'est déjà fait dans le script awk !!!...)

• Mettre le répertoire NETCDF contenant les fichiers NetCDF dont TAF a besoin dans le répertoire ASSIMILATION (Commentaires EK: Ici, je pense qu'on pourrait aussi commentre NETCDF et utiliser $assimil-name pour l'avoir avec les autres drivers/modules pour l'assimilation !!!! A discuter)

Etape 2: Mise au format du tag/trunk d'ORCHIDEE pour TAF

Deux principales taches sont effectuées par le script awk makeorchidee_fcm:

• une mise au format du tags/trunk d'ORCHIDEE pour TAF
• un regroupement de tous les codes incluant les nouveaux drivers/modules dans même un répertoire modeles_optim_temp

• Aller dans le répertoire ORCHIDEE depuis le repertoire ASSIMILATION et exécuter:

  ORCHIDEE> makeorchidee_fcm [-d]optim 
  

  avec [-d] pour debug.
  Le script makeorchidee_fcm qui est décrit plus en détails au point 4) :
  • Copie les sources du répertoire NETCDF nécessaire pour TAF dans le répertoire ASSIMILATION (A enlever car effectuer plus haut???)
  • Crée un répertoire de travail temporaire modeles_optim_temp à partir dur répertoire ASSIMILATION
  • Met le répertoire ORCHIDEE dans modeles_optim_temp
  • Crée les fichiers d'initialisation dans ORCHIDEE/src_sechiba et ORCHIDEE/src_stomate
  • Met les contenus des répertoires ASSIMILATION et modeles_optim_temp dans le répertoire spécifique pour l'assimilation qu'on par la suite $REPASSIMIL. $REPASSIMIL vaut:
    • TANGEANT pour tangent linéaire
    • TANGEANT_VTL pour le tangeant vectoriel
    • ADJOINT pour l'adjoint

( Commentaires EK: Ca doit correspondre au choix que l'on fait pour le type d'assimilation (voir étape 1, le flag a$ssimil-name) !!!)

Etape 3 : Application de TAF pour la génération des routines dérivées

Tous les codes sont mis dans Ici, on fait passer le logiciel TA sur le code pour la génération des codes dérivés. Se placer dans le répertoire spécifique pour permettre à TAF de faire la dérivation des codes puis lancer puis lancer TAF pour la différentiation souhaitée, e.g., TL (tangent linéaire) , VTL (tangent linéaire vectoriel), AD (code adjoint). Assurez-vous que vous avez le droit d'executer le script staf de TAF. Dans ce cas, assurez-vous que vous lancer ce script dans votre répertoire pour la dérivation des codes.

• Si vous souhaitez avoir juste les codes dérivés par TAF pour:
  • le tangent linéaire TL dont les sources portent l'extension _tl.f90, lancer:

    gmake tlm
    

  • le tangent vectoriel VTL dont les sources portent l'extension _vtl.f90, lancer:

    gmake vtl
    

  • l'adjoint AD dont les sources portent l'extension _ad.f90, lancer :

      gmake adm  (n'existe pas encore!!!)
    

• Si voulez compiler le code mis au format TAF en mode direct, i.e., comme ORCHIDEE standard (executable orchidee_ol_tg dans le répertoire bin), lancer:

  gmake 
  

• Si vous souhaitez générer à la fois les codes dérivés par TAF et/ou les compiler pour:
  • le tangeant linéaire TL (executable orchidee_ol_tl mis dans le répertoire bin), lancer:

    gmake tsttlm 
    

    • le tangent vectoriel VTL (executable orchidee_ol_vtl dans le répertoire bin), lancer:

      gmake tstvtlm
      

    • l'adjoint AD (executable orchidee_ol_ad !!! dans le répertoire bin), lancer:

      gmake tsadm  ( n'existe pas encore !!!)
      

Pour plus détails, voir le Makefile dans le répertoire spécifique à l'assimilation $REPASSIMIL que vous souhaitez réaliser.

3. Description des nouveaux drivers/modules pertinents pour la dérivation du code d'ORICHIDEE par TAF et son exécution

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 au préalable. Comme mentionné au poin 1., il faut passer à TAF une subroutine/fonction model(n,x,f) avec n et x les arguments d'entée et f étant l'argurment de sortie. On note: n, le nombre de paramètres pour lesquels on veut calculer les sensibilités x, le vecteur décrivant les valeurs des paramètres f, la fonction coût construite sur les variables auxquelles dépendent les paramètres 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. C'est une subroutine qui s'appelle:

model.f90  (A changer de nom ou OK???)

La subroutine model.f90 permet d'effectuer grosso modo les opérations suivantes:

• Allocation/Initialisation? de la plupart des variables SAVE d'ORCHIDEE à partir du module:

  mo_model.f90 ( A voir si on modifie ce nom !!)
  

• Simulation d'ORCHIDEE en bouclant sur le temps par appel à:

  intersurf_main_2D du mdule intersurf.f90 
  

• A la fin de la boucle de temps, le calcul de la fonction coût à partir du module:

  mo_cost.f90
  

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 mises dans un vecteur x. Le code ORCHIDEE dans sa forme standar n'est pas conçue de cette façon. En effet, les paramètres sont utilisés en dur dans 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 à fournir à model.f90. Ces modules qui sont décrits ci-après et qui sont mis dans le répertoire ASSIMILATION, permettent:

• d'avoir des informations sur le dimensionnement de la simulation du modèle ORCHIDEE, i.e., dimensions temporelle et spatiale
• d'avoir des informations sur le nombre de paramètres d'ORCHIDEE à optimiser
• de mettre les valeurs des paramètres d'ORCHIDEE avec leurs noms spécifiques dans un vecteur
• de remettre les valeurs des paramètres mis dans le vecteur aux noms des paramètres tels que décrits dans ORCHIDEE

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 la compilation code mis au format TAF sont détaillés au point d.

a) Informations sur le dimensionnement de la simulation d'ORCHIDEE

Nous avons créé un nouveau module basé sur le module readdim2.f90 d'ORCHIDEE standard. Ce nouveau module s'appelle:

mo_process.f90   (nom sans doute à changer !!!)

b) Informations sur les paramètres d'ORCHIDEE à optimiser

Les modules suivants ont été développés pour:

• l'initialisation des constantes et des paramètres pour l'optimisation

  constantes_optim.f90
  parameters_optim.f90 
  

• l'interfaçage des paramètres à optimiser avec le code d'ORCHIDEE

   interface_optim.f90   
  

c) Information sur le nombre de paramètres et la mise en vector des paramètres pour TAF/ORCHIDEE (vice/versa)

Pour l'accès au nombre de paramètres, la mise en vecteur de leurs valeurs, nous avons développé le module suivant:

mapping.f90

Ce module permet également de remettre les valeurs des paramètres du vecteur aux noms des paramètres dans ORCHIDEE.

d) Autres modules pour l'exécution d'ORCHIDEE mis au format pour TAF pour la construction des exécutables du code ORCHIDEE mis au format pour TAF en mode direct et des codes dérivés (i.e., tangeant linéiare TL, tangeant linéaire vectoriel VTL et adjoint AD), nous avons développé de nouveaux modules prepost.f90 et prgcost2.f90 dont un est spécifique au type de code dérivés (i.e., TL, VTL, et AD) que l'on souhaite utiliser.

• Appel des subroutines/fonctions pour les initialisations des paramètres (nombre et vecteur) par

  prepost.f90
  

• Compilation des différents codes: Voici le programme principal pour le code:
  • direct:

     prgcost2.f90
    

• tangeant linéaire (TL):

    prgtsttlm.f90
  

• tangent linéaire vectoriel (VTL):

    prgtstvtlm.f90
  

• adjoint

   prgadm.f90  (N'existe pas encore !!!=
  

4. Description de la mise en format automatique du code ORCHIDEE pour l'assimilation par le script makeorchidee_fcm

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 awk) pour la mise au format automatique du code d’ORCHIDEE pour TAF. La démarche pour cette mise au format se fait en quatre étapes suivantes et ces différentes sont effectuées en une seulle opération par l'opérateur par le ancement du sccript makeorchidee_fcm dans le répertoire ORCHIDEE:

ORCHIDEE> makeorchidee_fcm -optim 

Toutes les opérations effecutées par ce script sont détaillées en trois étapes:

Etape 1 : Chargement des routines d’ORCHIDEE/IOIPSL/TAF pertinents pour l’optimisation que l'on veut réaliser dans un répertoire de travail

• Copie les sources du répertoire NETCDF nécessaire pour TAF dans modeles/ASSIMILATION
• Crée un répertoire de travail temporaire modeles_optim_temp à partir du répertoire modeles.
• Met le répertoire d’ORCHIDEE dans le répertoire modeles_optim_temp

Etape 2 : Préparation des routines d’ORCHIDEE pour la mise au format pour TAF

makeorchidee_fcm se place dans modeles_optim_temp/ORCHIDEE_OL et :

• configure le Makefile dans ce répertoire pour enlever les pré-compilations PARALLEL et ASSIMIL
• 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 :

Etape 3 : Création des routines pour TAF

Boucler sur le/les fichiers sources de chaque répertoire deux fois avec deux scripts awk

• script 1 : ASSIMILATION/TOOLS/variables.awk
  • Avant IMPLICIT NONE :
    • Garder les USE dans le fichier $rep_init_alloc ( => à voir ... )
  • Entre IMPLICIT NONE et CONTAINS :
    • 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 TANEGANT
    • 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.
  • Couper les variables SAVE locales (dans les fonctions)dans les fichiers $rep_init_alloc du répertoire traité. Mettre ces variables dans le fichier $rep_init_alloc. Aussi, toutes ces variables sont désormais PUBLIC. Attention à se conformer à la règle de programmation pour éviter la redondance !!! 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 !!!

• Ajouter CONTAINS à la suite dans le fichier $rep_init_alloc

• script 2 : ASSIMILATION/TOOLS/subroutines.awk
  • Lire la phrase " List of subroutines for initialization :" » et construire un tableau init_functions qui lit chaque ligne commençant par "!-". Exemple :

    ! List of subroutines for initialization :
    !- routing_init
    !- routing_clear
    !- routing_diagnostic_p
    !- routing_diagnostic
    !- routing_basins_p
    !- routing_basins
    !- routing_getgrid
    !- routing_sortcoord
    !- routing_findbasins
    !- routing_simplify
    !- routing_cutbasin
    !- routing_hierarchy
    !- routing_findrout
    !- routing_globalize
    !- routing_linkup
    !- routing_fetch
    !- routing_truncate
    !- routing_killbas
    !- routing_names
    !- routing_irrigmap
    

• Couper les fonctions init dans init_alloc pour inclusion dans $rep_init_alloc
• Gérer/simplifier les appels du module d'optimisation depuis intersurf.f90 ???
• Retravailler les parties driver/readdim2.f90
• Copier toutes les sources de modeles_optim_temp dans le répertoire dédié à l'assimilation noté $REPASSIM (i.e., TANGEANT pour TL, TANGEANT_VTL pour VTL et ADJOINT pout AD)
• Copier toutes les sources du répertoire ASSIMILATION $REPASSIM
• Copier le Makefile du répertoire ASSIMILATION dans $REPASSIM
• Copier les sources NetCDF dans le répertoire $REPASSIM
• Supprimer modeles_optim_temp

5. Questions/Reflexions?

• 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" pour conserver les optimisations dans les futures développements)

• Gestion des « includes » des directives TAF: Il faut noter que cela se fait dans model.f90 mais doit être spécifique à chaque version pour l’optimisation et aussi à la version de IOSPL. Ce n'est pas simple de gérer automatiquement les directives TAF parce qu'on ne sait pas 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 argumens 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.

  !$TAF SUBROUTINE calendar::ymds2ju INPUT  = 1,2,3,4
  !$TAF SUBROUTINE calendar::ymds2ju OUTPUT = 5
  !$TAF SUBROUTINE calendar::ymds2ju REQUIRED
  

• 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 a 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 !!

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

  INTERFACE intersurf_main
  MODULE PROCEDURE intersurf_main_2d, intersurf_main_1d, intersurf_gathered, intersurf_gathered_2m
  END INTERFACE
  

  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:

     PUBLIC :: intersurf_main_2d, stom_define_history, intsurf_time, intsurf_restart,l_first_intersurf
  

• les sources NetCDF: TAF a besoin de certaines sources NEtCDF. On met ces sources dans le répertoire ASSIMILTION/NETCDF tel que décrit à l'étape 1. Pour leurs utilisations par TAF, voir le Makefile dans TANGEANT. Voici la liste de ces sources:

  netcdf_attributes.f90
  netcdf_dims.f90
  netcdf_expanded_modif.f90
  netcdf.f90
  netcdf_overloads.f90
  netcdf_text_variables_modif.f90
  netcdf_visibility.f90
  netcdf_constants.f90
  netcdf_expanded.f90
  netcdf_externals.f90
  netcdf_file.f90
  netcdf_text_variables.f90
  netcdf_variables.f90
  typeSizes.f90
  

  Comment gérer ces sources NetCDF? Les commettre ces sources ?

• Gestion de la liste des modules. Le faire dans le AA_make dans $REPASSIM ?
• Conformité aux règles de programmation ???
• Unicité des variables dans les différents modules ???

18/11/2011: Réunion de travail

Martial Mancip (MM), Ernest Koffi (EK), Philippe Peylin (de passage)

Discussions sur les différentes étapes à suivre pour l'efficacité du travail avec Fastopt.

Situation actuelle

Nous avons 3 versions du code "Assimilation"

• V1: Version du code envoyée à Fastopt par le LSCE en mai 2011
• V2: Version V1 travaillée par Fastopt pour créer à Fastopt le code tangent avec l'option -keep. Version envoyée au LSCE en septembre 2011. Test effectué au LSCE avec succès
• V3: Version actuelle du code au LSCE dans la branche "Assimilation"

Prochaines étapes à courte échéance

1) Travail à faire par LSCE pour Fastopt

• MM crée un répertoire privé sous svn pour Fastopt (on appelle ce répertoire fastopt)
• EK construit une ligne de commande svn import pour fastopt et envoie un e-mail à Fastopt
• Fastopt dépose sa version actuelle dans ce répertoire

2) Travail à faire au LSCE pour le suivi du travail

• Faire passer la version récente de TAF sur la version du code dans la branche "Assimilation"
• Analyser et documenter les différences entre les différentes versions V1, V2, et V3 décrites ci-dessus
  • V1 et V2
  • V3 et V2
• Envoyer un e-mail à Fastopt pour informations sur les différences

---

23/05/2011: E-mail envoye a Thomas Kaminski pour la version actuelle d ORCHIDEE pour Assimilation

Hello Thomas,

We have now fixed the problem on the compilation of ORCHIDEE model by using the option "--chkglobal" with lf95. The forward run test has also been performed (i.e., call three times the model, the two first ones without the change of the parameters (as priors), and the last one by perturbing the priors).

1. The new version of the ORCHIDEE model shaped for TAF can be found from our ftp server here: (These documents are only available on this server for a period of 7 days):

​ftp://ftp.cea.fr/incoming/y2k01/orchidee

Note that the previous provided readme file is still valid. For this new version, some additional netcdf files have been considered for the runing of TAF (see the line 17 in the file AA_make in the directory ORCHIDEE_OL to indicate the right path:, i.e, NETCDF_SRC).

2. In parallel, we are working on the generation of the tangent linear codes of the model with TAF and we have experienced some recurrent errors and warnings. Find hereafter some of them:

• An error on the string length: " INTERNAL ERROR: string too long." We do not understand this error since we have set the maximum length of the string to 130 throughout ORCHIDEE model and set to 132 in the command line for TAF in the Makefile. For more details on this error and others, see the output file from TAF running (i.e., taf_output_current and taf-tlm-current.log in the directory TANGEANT).

• The following recurrent warning for several routines, e.g., : " *WARNING* : model.f90:463 : call of intersurf_main too many arguments (44) defined = 0" (see in the file taf-tlm-current.log).

• TAF seems to not handle the following fortran command, as e.g., this line in some netcdf files: localMap (:numDims ) = (/ 1, (product(localCount(:counter)), counter = 1, numDims - 1) /)

We have then made some modifications in such netcdf files and also made compliant some parts of the ORCHIDEE model to proceed further with TAF. For more details, we have provided the netcdf files we are using including both the original and modified files (i.e., netcdf_expanded.f90 and netcdf_text_variables.f90; see in the directory NETCDF in TANGEANT).

Note: As it is built now the Makefile for the generation of TL codes (exec tlm), one needs to compile the forward model before, otherwise there is an error. This needs to be fixed.

3. Issues on the generated TL codes by TAF

As already mentionned, TAF seems to generate TL codes, but we think that these codes are incompleted. However, we have tried to compile them. Hereafter are some problems we encountered:

• The generated TL codes by TAF have sometimes string length over 132 characters. Of course, such a length is not allowed by the lf95 when considering the stricted options of this compiler. As an example, the generated TL code for TL relevant to the module intersurf.f90:

subroutine intersurf_main_2d( kjit, iim, jjm, kjpindex, kindex, xrdt, lrestart_read, lrestart_write, lon, lat, zcontfrac, & &zneighbours, zresolution, date0, zlev, u, v, qair, temp_air, epot_air, ccanopy, cdrag, petacoef, peqacoef, petbcoef, peqbcoef, & &precip_rain, precip_snow, lwdown, swnet, swdown, pb, vevapp, fluxsens, fluxlat, co2_flux_tot, coastalflow, riverflow, tsol_rad, & &temp_sol_new, qsurf, albedo, emis, z0 )

Can you clarify us on these issues ? Thanks.

Please do not hesitate to contact us for any clarifications and additional questions.

Best regards,

Ernest & Martial

---

Reunion du 20/04/2011 sur l etat d avancement du travail sur l assimilation d ORCHIDEE avec TAF

Presents: Catherine Ottle (CO), Cedric Bacour (CB), Philippe Peylin (PP), Sylvain Kuppel (SK), Abdou Kane (AK), Martial Mancip (MM), Ernest Koffi (EK)

EK presente les objectifs de ce travail et son avancement (voir presentation. Est-ce possible de mettre cette presentation ici ?)

En resume, il faut adapter ORCHIDEE de telle sorte qu'on puisse l appeler comme une fonction model(n,x,fc): avec n le nombre de paramatres du modele a optimiser, x le vecteur parametres et fc la fonction cout en fonction des variables pour lesquelles les parametres sont optimises. Ensuite, il faut compiler le modele avec le compilateur lf95 en utilisant les options les plus strictes possibles de ce compilateur, en occurence l option --chkglobal. Ce travail est effecute par EK et MM.

Etat d avancement

1. Modele direct
   • Mise en forme du modele telle que decrite ci-dessus effectuee
   • Compilation du modele sans l option --chkglobal: OK
   • Test du modele sans l option --chkglobal: OK. Ce test consiste a appeler ORCHIDEE deux fois de suite sans modifier les parametres et s assurer que la fonction cout est la meme. Ceci suppose que toutes les initialisations/deallocations des tableaux du modele ont ete bien effecuees. Ensuite, un troisieme test suivant les deux precedents en perturbant les parametres.
   • Compilation du modele avec l option --chkgloabl: OK, mais le modele plante a l execution.

2. Modele tangeant lineaire (TL)
   • Code TL genere mais ne compile pas.

3. Cette version du modele suit la structure de compilation/gestion du modele ORCHIDEE generique

4. Une branche Assimilation est cree : ​http://forge.ipsl.jussieu.fr/orchidee/browser/branches/Assimilation

5. Discussions:

• Calcul de la fonction cout

CB pose la question sur la maniere dont on calcule la fonction cout de la nouvelle version d ORCHIDEE pour l assimilation. En effet, la fonction cout considere les observations pour les variables pour lesquelles on optimise les parametres. Dans la version TL qui utilise seulement une partie du modele et qui marche (travail de Francois Delage (FD) et Cedric Bacour), la fonction cout est calcule a partir de toutes les variables modelisees pour lesquelles on cherche a optimiser les parametres. L argument principal justifiant cette deuxieme maniere de calculer la fonction cout est qu'une fois les codes TL generes, on y revient plus sauf s il y a une modification majeure. EK pense que les 2 options sont equivalentes pour TAF et surtout que la generation des codes TL par TAF ne prend pas de temps (i.e., une fois que les codes ont ete bien generes) . Ainsi, une modification du code avec ajout d autres variables/parametres ne necessite pas un travail supplementaire important. Il est neamoins prevu de considerer les deux options dans le but de comparer les codes TL.

• Directives TAF

CB demande si les directives TAF utilisees par FD et CB ont ete conservees. En grande partie oui, sauf les directives dans le nouveau model.f90 ont ete enlevees. Une verification faite apres la reunion montre que les codes TL generes par TAF avec ou sans ces directives restent identiques.

• Option -keep de TAF

EK pense que cette option ne devrait pas etre consideree car TAF analyse les liens entre les entrees et sorties du modele. Cette option utilisee apres la reunion permet neanmoins d avoir un nombre de modules legerement eleve pour lesquels le code TL est cree. Neanmoins ce code TL ne compile toujours pas.

---

23/03/2011 E-mail and ORCHIDEE codes sent to FastOpt? in the framework of the work on TL & AD codes of ORCHIDEE by TAF

Dear Thomas,

We have now a version of the whole ORCHIDEE model shaped for TAF, which allows keeping the model structure in order to benefit for any improvements of the model. This version: 1) considers the main driver of ORCHIDEE as a subroutine called model (n,x,fc) with n the number of the parameters, x the parameters vector and the cost function fc. The parameters are the default values of ORCHIDEE model parameters and obtained during the initialisation of the model.

2) compiles with lf95

3) We have succesfully made the following tests with this version:

• two consecutive calls of model(n,x,fc) with the same set of parameters: the cost function is OK:, ie., the same value as expected
• A third run after the two aboved mentionned with the set of parameters perturbed: the cost function is different as expected.

4) We have started generating the TL codes with TAF with this version without the option -keep, but the work is still ongoing (Note that the reduced version of ORCHIDEE as previously provided to you is working well with TL codes used for our needs). Indeed, with this version, TAF starts to generate the codes and produces some TL codes which are not yet completed. However, to allow you making use of the code, I have put the current version of the code called here "Assimilation.tar.gz" on our ftp server:

​ftp://ftp.cea.fr/incoming/y2k01/orchidee (Note that the data are on this ftp server only for one week from now)

( If you wish to take the data from UNIX/LINUX: ftp ftp.cea.fr Name (ftp.cea.fr:...): anonymous Password: just put enter ftp> cd incoming/y2k01/orchidee Then you can get the data )

You will find a readme file (detailled below), which gives the various steps to be followed for both the compilation and the running of the ORCHIDEE code shaped for TAF:

A/ Having the ORCHIDEE model shaped for TAF

1. go to the directory "util"

2) do ins_make -t lf95. This will create automatically the Makefiles in the directories modeles/ORCHIDEE and modeles/ORCHIDEE_OL where are stored the main codes of ORCHIDEE and the directory "modeles/ORCHIDEE_OL/TANGEANT" where the following drivers (i.e. model.f90, prgcost2.f90, etc..) are stored .

2. go to the directory "ORCHIDEE_OL"
3. do gmake tangeant. This will shape all the codes for TAF and put them in the same directory called "TANGEANT".

B/ Compilation of the codes shaped for TAF in forward mode

1. go to the directory "TANGEANT"
2. do gmake. The exec "orchidee_ol_tg" is stored in ../../../bin

Actions A/ and B/ can be executed automatically by using the script shell called "arrange_orchidee_for_taf": do arrange_orchidee_for_taf and the codes are pop on in the directory modeles/ORCHIDEE_OL/TANGEANT.

C/ Running the ORCHIDEE model in forward mode We have prepared a set of data in the directory "post" (i.e., inputs, ....) for a test run:

1. go to the directory post
2. Before runing the code, ensure that the run parameters are OK for you. The run definition file is called "run.def". For an example, the time length of the run goto about line 498 ( change TIME_LENGTH if necessary , e.g. TIME_LENGTH= 2D for two days of simulation). For the other parameters, you do not need to change them for this test.
3. Ensure that there are not any restart files in the output directory called "output". In case they are some restart files, the run can stop. To avoid this, we have created a script called "lance" which cleans this directory before the run.

Note that in the current configuration of this forward code, we call three times ORCHIDEE: the first and second ones use the same values of the parameters and the third one with a perturbed parameters.

D/ Generating ORCHIDEE TL For generating TL and other codes from TAF, the Makefile under TANGEANT can be modified if necessary. However, for the current configuration, to generate TL

1. goto the directory TANGEANT
2. do gmake tlm, but it still does not generate a complete TL code as mentionned earlier.

E/ Other details: NETCDF stuff in the Makefile under the directory TANGEANT needed for TAF. Give the right netcdf links at lines 54 and 55 of the current Makefile. NCDF_INC = NCDF_LIB = . In the current version, for TAF we use 3 files (netcdf_constants.f90, typSizes.f90, netcdf.f90 in the directory TANGEANT) relevant for netcdf. Note that these files are not in the repository of ORCHIDEE ! Of course, the link to taf "staf" needs to be provided at line 159 in the current Makefile

Hope that clarifies the matter and thus we can start efficiently work with the code to fulfill our objectives.

Please do not hesitate to ask us (I and/or Martial) for any clarifications/questions about this version.

With our best wishes,

Ernest and Martial

08/12/2010 Réunion sur l'externalisation des paramètres d'ORCHIDEE

(Didier Solyga, Martial Mancip, Ernest Koffi)

Pour l'externalisation des paramètres d'ORCHIDEE, il y a actuellement deux versions du modèle:

1. version utilisée pour l'assimilation (Delage/Cedric/Ernest?: ci-après version DCE) et
2. la version d'externalisation générique (Didier: version DM).

Fusion des versions

On a parcouru les modules relatifs à l'externalisation de ces 2 versions citées ci-dessus. Globalement, ces 2 versions peuvent être fusionnées. Néanmoins ceci nécessitera un travail assez important.

• version CDE: l'externalisation des paramètres se fait dans le module interface_optim.f90
• version DM: l'externalisation se fait dans 2 modules: constantes.f90 and pft_parameters.f90
• La version DCE est bien avancée, mais des problèmes restent à résoudre pour la rendre flexible. Particulièrement les deux points suivants ont été discutés:
  1. Le gros du travail concernerait la structure du module interface_optim.f90
  2. En détail, e.g., la structure actuelle de dépendence des paramètres au temps de la version DCE est pour le moment trop rigide. En effet, tout ajout ou modfication de la liste des paramètres nécessitera des modifications à plusieurs endroits du code.

Coordination des travaux

Un nombre de paramètres important a déjà été externalisé pour l'assimilation. On s'est aperçu que certain d'entre eux avaient aussi été externalisés dans la version DM et ne voulaient pas dire la même chose !
exemple Q10 dans stomate_litter :

• version DCE :

      !!>ORCHIS
      !!tempfunc_result(:) = EXP( 0.69 * ( temp_in(:) - (ZeroCelsius+30.) ) / 10. )
      tempfunc_result(:) = EXP( LOG(q10(:)) * ( temp_in(:) - (ZeroCelsius+30.) ) / 10. )
      !!<ORCHIS
  

• version DM :

     tempfunc_result(:) = exp( soil_Q10 * ( temp_in(:) - (ZeroCelsius+tsoil_ref)) / Q10 )
  

Il est donc impératif que P. Peylin et N. Viovy tranchent sur les définitions exactes.

Actions:

• Didier doit s'assurer qu'il externalise au moins les paramètres utilisés dans l'assimilation

Autres: Préparation du code pour l'adjoint

Pour l'adjoint d'ORCHIDEE, FastOpt? veut un code préalablement compilé par le compilateur lf95. Martial n'a réussi à compiler le code qu'en mettant tous les codes sources dans le meme répertoire. Plus particulièrement, les difficultés sont survenues sur les modules parallel.f90 et slowproc.f90. Est-ce un défaut du compilateur? La question reste posée.

19/11/2010

réunion de préparation de l'acceuil de Thomas Kaminski (équipe FastOpt?)

• On a constaté le conflit de compilation du code modifier par François Delage pour TAF. On a simplifier cette compilation : travail sur l'initialisation du routage. Après demande cette question qui lui a été posée :
  Bonjour François,
  Nous poursuivons ton travail et de fois viennent des questions comme celles de Martial formulées ci dessous. Peux-tu nous éclairer urgemment sur ce point car nous recevrons Thomas Kaminski le jeudi 25 novembre pour travailler sur le code.
  Une première réponse de sa part a été :
  Tout simplement parce que la subroutine routing ne contenais pas de variables independantes et n'etait donc pas une subroutines active que ce soit pour l'adjointisation ou pour la linéarisation. Si je me souviens bien, il existe deux version de routages dans orchidee et j'avais surement decidé de gagner du temps en sortant routing du process.
  Il y a surement d'autres raisons mais ca me vient pas la naturellement.
  Il semble que ce choix est judicieux, car il permet d'incorporer plus simplement les directive pour l'assimilation dans le code SVN de ORCHIDEE.
  
  • Martial doit faire ces tests d'incorporation et de compilation.
  • Ernest doit tester cette première version modifiée avec TAF.
• On a analyser les scripts de pré-travail présents dans le répertoire bin/preproc. Pour automatiser la création du modèle modifier, on doit re-travailler le script launch_preproc.ksh. On aura l'arborescence classique après récupération du modèle avec util/model puis installation standard des Makefiles avec util/ins_make.
• voir REUION_19-11-10​

02/08/2009

Réunion de préparation du voyage vers FastOP
Le but est de cette réunion était de comprendre la chaîne de compilation pour fabriquer le tangeant linéaire.
Une simplification de cette chaîne est possible. Les notes succintes concernant cette chaîne et des améliorations possibles est attaché à cette page : COMMENTAIRES_compilation​