This is a page which can contain reports from other specific meetings about ORCHIDEE

---

10/10/2013 - Technical meeting on the routing scheme

Present : Agnès Ducharne (AD ; secretary), Josefine Ghattas (JG), Betrand Guénet (BG), Matthieu Guimberteau (MG), Ronny Lauerwald (RL), Jan Polcher (JP), Camille Risi (CR), Ana Schneider (AS)
Ana's slides ​http://www.sisyphe.jussieu.fr/~ducharne/documents/Routing_10dec13.pdf

The main equation of the routing scheme is found in subroutine routing_flow .f90:
flow=MIN(i_reservoir/((topo_resid/1000.)*i_tcst*one_day/dt_routing), i_reservoir(i)-min_sechiba)
i_flow(ig,ib) = MAX(flow, zero)

• flow is in kg/dtrouting,
  
• i_reservoir is in kg,
  
• one_day and dt_routing are in seconds, and are equal by default,
  
• i is a surrogate for fast, slow, or stream, and corresponding i_tcst values defined in the routing module, supposedly in day/m : slow_tcst_cwrr = 25.0 ; fast_tcst_cwrr = 3.0 ; stream_tcst_cwrr = 0.24

T_i = (topo_resid*i_tcst/1000.) gives the characteristic timescale of reservoir i, in days. In this parameter T_i, topo_resid describes the effect of the grid-cell morphology (via the streams' length and slope), while i_cst gives the characteristic velocity of the reservoir, with a dimension of [T/L]

We had a first meeting on October 24th, with AD, MG, RL, and AS, in which we started to analyse the source code of routing.f90.
Questions remained about the actual units of topo_resid (read from the file routing.nc) and i_cst, given the presence of a 1000 factor.

After a careful look at the values in routing.nc, the scripts Jan developped to create routing.nc, classical velocities of large rivers found in the literature, and considering the fact that the routing scheme simulates satisfactory river discharges in off-line mode, we conclude that :

• topo_resid is in km routing.nc
  
• the characteristic velocity of the reservoirs is (i_tcst/1000.) in days/km
  

The code comments should be corrected accordingly. We suggest to remove the division by 1000 from the code, and to integrate it directly when defining i_tcst in the module :slow_tcst_cwrr = 25.0/1000. ; fast_tcst_cwrr = 3.0/1000. ; stream_tcst_cwrr = 0.24/1000. !! in days/km

We then discussed the possibility to use higher resolution topographical datasets to calculate topo_resid, which is presently defined at the 0.5° resolution, based on the dataset produced at the same resolution by Vorosmarty et al. (2000) : Global system of rivers: Its role in organizing continental land mass and defining land-to-ocean linkages, Global Biogeochem. Cycles, 14, 599–621.

The main two options are to start from Hydro1k (​http://webgis.wr.usgs.gov/globalgis/metadata_qr/metadata/hydro1k.htm) or HydroSHEDS (​http://hydrosheds.cr.usgs.gov/index.php), which are both hydrologically conditionned DEMs, at the 30 arc-sec =1 km and 15 arc-sec resolution respectively. Hydro1k does not use a global projection, which may induce continuity problems. HydroSHEDs does, but lacks information at high latitudes (above 60°), which is problematic for all Arctic rivers.

We propose to better analyze the pros and cons of the two datasets, as part of the PhD thesis of AS, supervised by AD. JP will provide support to ascertain the precise information required by ORCHIDEE. Marie Sylvestre, specialist of Geographic Information Systems (GIS) in Sisyphe, will provide technical support. We will submit this work to the ORCHIDEE group before for final decision.

---

Réunion 04/07/2013 : Bilan réunion Couplage ORCHIDEE - ATM via OASIS

Présents : Jan Polcher, Marc Stéfanon, Yann Meurdesoif, Arnaud Caubel, Anne Cozic, Philppe Peylin, Josefine Ghattas

Objectif : D'analyser l'intérêt pour le groupe ORC d'un potentiel couplage ORC-LMDz via OASIS et/ou de l'utilisation de OASIS pour faire des simulation en mode forcé.

Marc à présenté l'état du couplage ORCHIDEE-WRF via OASIS-MCT (la dernière version d'OASIS); nous avons ensuite discuté des bénéfices et inconvénients d'une approche avec OASIS. Voir ici ​la présentation de Marc.

• Potentiel avantages d'OASIS:
  • Tout d'abord OASIS permet de lancer deux exécutable (ORCH et le modèle d'atmosphère), ce qui permettrait à terme de "de-synchroniser" les modèles et donc d'avoir ORC qui fait certain calculs après avoir retourné au modèle d'atmosphère les champs du bilan d'eau et d'énergie. Yann mentionne que cela n'a de réel intérêt que si le cout calcul de ORC est significatif par rapport a celui de l'atmosphère
  • Si l'on considère 3 modèles (ORC, ATM, OCEAN) alors OASIS peut simplifier les couplages 2 à 2 sans avoir à passer par le modèle d'atmosphère pour envoyer le routage de l'eau à l'océan.
  • Si l'on envisage des grilles de résolutions différentes entre l'atmosphère et ORC, alors OASIS permettra de gérer plus facilement les interpolations à chaque pas de temps.
  • Parallélisation: Pour le moment ORC est parallélisé avec une subdivision selon un ensemble de points continu en longitude (c'est a dire par bande couvrant ou non toutes les longitudes mais pas par domaine rectangulaire). OASIS a permit le couplage ORC-WRF par bloc rectangulaire ce qui correspondait au découpage dans WRF. Néanmoins Yann mentionne que l'on peut aussi envisager le découpage par bloc carré avec un couplage direct (quelques changements a faire dans ORC.)

• Potentiels inconvénient d'OASIS:
  • Les performances informatiques restent à vérifier. Jan a fait des premiers tests en mode forcé avec OASIS ou avec l'ancien driver qui donnent des résultats similaire. Néanmoins ce test inclus des modification du driver dans OASIS (sur la lecture des forçages en particulier) ce qui impacte probablement les performances globales. Il faudrait donc refaire des tests avec "driver" identiques.
  • Yann mentionne que la parallélisation OMP, vers laquelle on se dirige, n'est pas encore possible avec OASIS-MCT
  • Les simulations avec OASIS nécessitent de porter OASIS sur chaque machine (et le compiler) ce qui peut être "lourd" et surtout nécessite des ressources
  • Il est clair que pour LMDZ, le couplage "directe" ORC-LMDZ restera un mode de fonctionnement pour le futur proche (raisons de type contextuelles); Cela implique donc le maintient éventuel de deux voix de couplage.

• Stratégie collective et réflexions générales:
  • Jan et Marc vont poursuivre leur effort WRF-ORC via OASIS; Il essayeront de mieux caractériser les performance du coupleur vis a vis d'un couplage IDENTIQUE mais directe.
  • On a mentionné le problème des "ressources" qui restent limitées et donc la difficulté de maintenir deux système de couplage pour le groupe ORC.
  • On envisage dans un premier temps d'avoir en parallèle: i) WRF-ORC avec OASIS porté par LMD-Palaiseau, ii) Un couplage directe LMDz-ORC qui va intégrer XIOS et qui essaye de garder un oeil sur les développement du coté OASIS-WRF-ORC
  • Un problème soulevé concerne aussi les outils LIBIGCM: Quel est la stratégie du pôle de modélisation et du pole régional vis a vis de ces outils et de leur application éventuelle pour le modèle régionale et leur maintenance. Ce point sera relayé au Pôle de Modélisation.
  • Pour les aspect DRIVER et simulations forcées: Il est important d'essayer d'avoir a terme une seule approche! Dans un premiers temps il serait idéal que les développements de Jan sur la réécriture du Driver pour l'utilisation d'OASIS en forcé bénéficient au Driver standard! Ce point est à rediscuter pratiquement !
  • Yann pourrait éventuellement consacré un peu de temps sur une tache ciblé permettant de mieux comparer les deux approches.
  • On prévoit de murir la réflexion et de refaire un point à l'automne..
  • Commentaires de Jan :
    • Il est motivé pour mesure plus précisément la performance du driver prototype qui couple avec OASIS. Il demandera des conseils de Yann sur comment mesurer cela correctement
    • Il voudrait bien avec l'aide de quelqu'un (à définir) réfléchir à ce qui peut être porté du prototype à dim2_driver pour améliorer les performances. Cela sera plutôt pour Septembre

---