Changes between Version 7 and Version 8 of DevelopmentActivities/MergeHydro/Martial_notes_on_merge


Ignore:
Timestamp:
10/20/11 06:40:50 (10 years ago)
Author:
mmaipsl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DevelopmentActivities/MergeHydro/Martial_notes_on_merge

    v7 v8  
    3636}}} 
    3737  Il me semble utile de rajouter un getin pour cela, non ? 
    38  
     38 * 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 : 
     39{{{ 
     40             waterbal_error=.TRUE. 
     41             CALL ipslerr(2, 'hydrol_split_soil', 'We will STOP after hydrol_split_soil.',& 
     42                  & 'check_CWRR','PRECISOL SPLIT FALSE') 
     43}}}  
     44   sans le faire ! Est-ce à rajouter ?  
    3945== problèmes conversion (frac_bare/veget) versus (veget,veget_max) == 
    40    * dans hydrol_init : on passait veget (ie l'ancien veget_max) et on a pas changer le code par rapport 
    41      à l'ancienne version. On obtient peut-être des incohérences :  
     46 * dans hydrol_init : on passait veget (ie l'ancien veget_max) et on a pas changer le code par rapport 
     47   à l'ancienne version. On obtient peut-être des incohérences :  
    4248{{{ 
    4349       IF ( MINVAL(resdist) .EQ.  MAXVAL(resdist) .AND. MINVAL(resdist) .EQ. val_exp) THEN 
     
    5157       ENDDO 
    5258}}} 
    53      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. 
    54    * dans hydrol_vegetupd on utilise vraiment frac_bare : 
     59   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. 
     60 * dans hydrol_vegetupd on utilise vraiment frac_bare : 
    5561{{{ 
    5662    DO jv = 1, nvm 
     
    6066    END DO 
    6167}}} 
    62      On doit donc le recalculer à partir de la formule dans slowproc : 
     68   On doit donc le recalculer à partir de la formule dans slowproc : 
    6369{{{ 
    6470    frac_bare(:,:) = zero 
     
    7076    ENDIF 
    7177}}} 
    72     et la définition actuelle du veget : 
     78   et la définition actuelle du veget : 
    7379{{{ 
    7480    ! Ajout Nouveau calcul (stomate-like)  
     
    8288 [...] 
    8389}}} 
    84     On déduit alors en combinant ces deux définitions : 
     90   On déduit alors en combinant ces deux définitions : 
    8591{{{ 
    8692    frac_bare(:,1) = un 
     
    9399    ENDDO 
    94100}}} 
    95     L'utilisation du undef_sechiba me paraît cohérente lorsque l'on a pas de présence du PFT sur le pixel.[[BR]] 
    96     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. [[BR]] 
    97     Un problème surgit alors lorsque l'on définit : 
     101   L'utilisation du undef_sechiba me paraît cohérente lorsque l'on a pas de présence du PFT sur le pixel.[[BR]] 
     102   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. [[BR]] 
     103   Un problème surgit alors lorsque l'on définit : 
    98104{{{ 
    99105    tot_frac_bare(:) = zero 
     
    105111    ENDDO 
    106112}}} 
    107     car on ne teste pas veget_max > min_sechiba. Je le rajoute. 
     113   car on ne teste pas veget_max > min_sechiba. Je le rajoute. 
    108114 * hydrol_canop : je me pose la question du veget/veget_max ici car on définit qsintveg et precisol dans cette routine.  
    109115   Si l'on passe veget_max, on ne tient plus compte du LAI pour calculer ces deux variables importantes. Je laisse donc veget.