Martial notes for the merge

messages de TdO dans le module d'hydro

• l1

  !tdo - enlever toute profondeur variable pour voir l'effet sur l'efficacite du code
  

• l153

  !!! A CHANGER DANS TOUT HYDROL: tmc_litter_res et sat ne devraient pas dependre de ji - tdo
  

• hydrol_soil :

    SUBROUTINE hydrol_soil (kjpindex, dtradia, veget_max, soiltile, njsc, reinf_slope, &
         & transpir, vevapnu, evapot, evapot_penm, runoff, drainage, returnflow, reinfiltration, irrigation, &
         & tot_melt, evap_bare_lim,  shumdiag, k_litt, litterhumdiag, humrel,vegstress, drysoil_frac)
      ! 
      ! interface description
      ! input scalar 
      INTEGER(i_std), INTENT(in)                               :: kjpindex         !!
      !To be removed later
  

  kjpindex doit-il être supprimé de cette fonction ?? ou est-ce un commentaire obsolète ?? à rechercher dans les versions antérieures.

• deux commentaires dans la même fonction :

         !-
         !- step 6.5 : compute dr_ns with the bottom boundary condition 
         !- step 6.5 : initialize qflux at bottom of diffusion and avoid over saturated or under residual soil moisture 
         !-
  

  Le second à l'air obsolète ... à effacer ?
• Toujours dans hydrol_soil, un commentaire important l3211 :

               !- Here we make the assumption that roots do not take water from the 1st layer. 
               !- Comment the us=0 if you want to change this.
  

  Il me semble utile de rajouter un getin pour cela, non ?
• Concernant les erreurs de fermeture de bilan (cf variable waterbal_error), on indique plusieurs fois dans le code que l'on va l'arrêter :

               waterbal_error=.TRUE.
               CALL ipslerr(2, 'hydrol_split_soil', 'We will STOP after hydrol_split_soil.',&
                    & 'check_CWRR','PRECISOL SPLIT FALSE')
  

  sans le faire ! Est-ce à rajouter ?

problèmes conversion (frac_bare/veget) versus (veget,veget_max)

• dans hydrol_init : on passait veget (ie l'ancien veget_max) et on a pas changer le code par rapport à l'ancienne version. On obtient peut-être des incohérences :

         IF ( MINVAL(resdist) .EQ.  MAXVAL(resdist) .AND. MINVAL(resdist) .EQ. val_exp) THEN
            resdist = veget
         ENDIF
         !
         !  Remember that it is only frac_nobio + SUM(veget(,:)) that is equal to 1. Thus we need vegtot
         !
         DO ji = 1, kjpindex
            vegtot(ji) = SUM(veget(ji,:))
         ENDDO
  

  Dois-je laisser le veget de la version standard ?? a priori, je passe à veget_max car vegtot fait référence à 1-frac_nobio et est souvent divisé par veget_max.
• dans hydrol_vegetupd on utilise vraiment frac_bare :

      DO jv = 1, nvm
         DO ji =1, kjpindex
            tot_frac_bare(ji) = tot_frac_bare(ji) + veget_max(ji,jv) * frac_bare(ji,jv)
         ENDDO
      END DO
  

  On doit donc le recalculer à partir de la formule dans slowproc :

      frac_bare(:,:) = zero
      frac_bare(:,1) = un
      IF (extcoef .LT. 100) THEN
         DO jv=2,nvm
            frac_bare(:,jv) = EXP(-extcoef * lai(:,jv))
         ENDDO
      ENDIF
  

  et la définition actuelle du veget :

      ! Ajout Nouveau calcul (stomate-like) 
      DO ji = 1, kjpindex
         SUMveg = 0.0
         veget(ji,1) = veget_max(ji,1)
         DO jv = 2, nvm
            veget(ji,jv) = veget_max(ji,jv) * ( 1. - exp( - lai(ji,jv) * ext_coef(jv) ) )
            veget(ji,1) = veget(ji,1) + (veget_max(ji,jv) - veget(ji,jv))
         ENDDO
   [...]
  

  On déduit alors en combinant ces deux définitions :

      frac_bare(:,1) = un
      frac_bare(:,2:nvm) = undef_sechiba
      DO jv = 2, nvm
         DO ji = 1, kjpindex
            IF ( veget_max(ji,jv) .GT. min_sechiba ) &
                 frac_bare(ji,jv) = 1 - veget(ji,jv) / veget_max(ji,jv)
         ENDDO
      ENDDO
  

  L'utilisation du undef_sechiba me paraît cohérente lorsque l'on a pas de présence du PFT sur le pixel.
  On avait d'ailleurs une erreur avant avec le frac_bare car il était parfois définit (utilisé ?) lorsque veget_max(ji,jv) était nul.
  Un problème surgit alors lorsque l'on définit :

      tot_frac_bare(:) = zero
  [...]
      DO jv = 1, nvm
         DO ji =1, kjpindex
            tot_frac_bare(ji) = tot_frac_bare(ji) + veget_max(ji,jv) * frac_bare(ji,jv)
         ENDDO
      ENDDO
  

  car on ne teste pas veget_max > min_sechiba. Je le rajoute.
• hydrol_canop : je me pose la question du veget/veget_max ici car on définit qsintveg et precisol dans cette routine. Si l'on passe veget_max, on ne tient plus compte du LAI pour calculer ces deux variables importantes. Je laisse donc veget.

traitement des corrections de Nathalie

Gestion du throughfall_by_pft

J'ai rajouté un booléen ok_throughfall_by_pft.

       IF ( ok_throughfall_by_pft ) THEN
          ! Correction Nathalie - Juin 2006 - une partie de la pluie arrivera toujours sur le sol
          ! sorte de throughfall supplementaire
          qsintveg(:,jv) = qsintveg(:,jv) + veget(:,jv) * ((1-throughfall_by_pft(jv))*precip_rain(:))
       ELSE
          qsintveg(:,jv) = qsintveg(:,jv) + veget(:,jv) * precip_rain(:)
       ENDIF

pour toutes ces corrections (dans hydrol_canop).

J'ai globalisé le OFF_LINE_MODE qui depuis intersurf indiquait si l'on utilisait une interface "intersurf_main*" (utilisation off-line du modèle) ou bien "intersurf_gathered*" (pour les utilisations on-line avec le GCM).

Comme convenu, j'ai donc imposé comme valeur par défaut de ce ok_throughfall_by_pft :

       ok_throughfall_by_pft = .FALSE.
       IF ( .NOT. OFF_LINE_MODE ) ok_throughfall_by_pft = .TRUE.

Messages de TdO dans le module de routage

Dans la procédure routing_truncate, un message et une modification de Tristan a attiré mon attention :

       ! tdo - To take into account rivers that do not flow to the oceans 
       IF ( route_tobasin(ff(1), ff(2)) .GT. nbasmax ) THEN
!       IF ( route_tobasin(ff(1), ff(2)) .EQ. nbasmax + 2) THEN

est-ce correcte ?

merge de sechiba

• A la fin de l'appel de hydrol_main, on a dans la version LMD :

            rsol(:) = -un
  

  Pourquoi cette initialisation a disparut dans la version standard.