Opened 9 years ago

Closed 8 years ago

#33 closed defect (fixed)


Reported by: jgipsl Owned by: aducharne
Priority: major Milestone: ORCHIDEE 2.0
Component: Physical processes Version:
Keywords: Cc:


LAND_USE=y and VEGET_UPDATE=0Y is OK with CWRR. But with VEGET_UPDATE=1Y the model stop. After call to hydrol_vegupd the moisture content (mc) can become to unrealistic high >1 (and even >1000).

Change History (6)

comment:1 Changed 9 years ago by jpolcher

This has never been tested or even developed. The redistribution of water among soil moisture columns when the vegetation fraction changes is a delicate issue if water needs to be conserved and the vertical gradients as well.

Martial wrote something but I do not know to which extent it was tested.

So some specific tests should be devised before the combination of flags allowing vegetation update and CWRR are allowed.

comment:2 Changed 9 years ago by acampoy

Pour être capable de changer de carte de végétation tous les ans
(LAND_USE=y ; VEGET_UPDATE=1Y), il a fallu revoir les subroutines
hydrol_vegupd et hydrol_tmc_update qui semblaient considérer
d’anciennes définitions de veget_max/veget/vegtot...

Les corrections apportées sont contrôlées par des CHECK_CWRR
qui fonctionnent aussi bien en forcé qu’en couplé (lmdz) global
sur plusieurs années si VEGET_UPDATE=0Y.

En revanche, si on impose VEGET_UPDATE=1Y, même si tous les CHECK_CWRR (avec ipslerr(3))
sont activé et ne s’alarment pas, il faut parfois désactiver CHECK_WATERBAL
lors du passage à une nouvelle carte de végétation, aussi bien en couplé lmdz
qu’en forcé. Si on réactive CHECK_WATERBAL en milieu d’année (en configuration couplé
qui impose des restart tous les mois), il faut attendre un changement de carte de végétation
pour que le CHECK_WATERBAL s’alarme au premiers pas de temps qui suit le changement de carte.

CHECK_WATERBAL active une subroutine (hydrol_waterbal) qui compare l’ensemble
des flux d’eau et la variation des réservoirs d’eau en début et fin de pas de temps :

tot_flux(ji) = precip_rain(ji) + precip_snow(ji) + irrigation (ji) - SUM(vevapwet(ji,:)) -

SUM(transpir(ji,:)) - vevapnu(ji) - vevapsno(ji) - vevapflo(ji) + floodout(ji)

  • runoff(ji) - drainage(ji) + returnflow(ji) + reinfiltration(ji)

tot_water_end(ji) = humtot(ji)*vegtot(ji) + SUM(qsintveg(ji,:)) + snow(ji) + SUM(snow_nobio(ji,:))

delta_water = tot_water_end(ji) - tot_water_beg(ji)

IF ( ABS(delta_water-tot_flux(ji)) .GT. deux*allowed_err ) CALL ipslerr(3, 'hydrol_waterbal', 'We will STOP ….

tot_water_beg = tot_water_end

Ce qui est étrange dans ce bilan d’eau, c’est la pondération de humtot (le contenue total en eau du sol)
par vegtot (=SUM(veget_max) et qui n’est pas toujours égale à 1 , c’est vegtot+fracnobio=1)
dans le calcul de tot_water_end.

Lors d’un changement de carte de végétation, humtot et qsintveg subissent des modifications
au cours du premier pas de temps dans hydrol_tmc_update, mais dont le bilan d’eau est contrôlé
par un CHECK_CWRR(ipslerr(3)), snow et snow_nobio ne sont pas changés (le faudrait-il ? Je ne crois pas).

En revanche, les veget_max changent, donc vegtot aussi, et le tot_water_beg
(lu dans le dernier fichier restart en début de pas de temps), n’est pas en accord
avec le tot_water_end calculé à la fin du premier pas de temps car il ne s’appuie pas sur le même vegtot.

J’ai donc l’impression que le bug rencontré lors d’un changement de carte n’est pas une erreur de bilan d’eau, mais une erreur dans le diagnostic de ce bilan (hydrol_waterball).
Le fait que les CHECK_CWRR ne s’alarment pas est rassurant, car l’arrêt du CHECK_WATERBAL a lieu en toute fin de pas de temps donc on est passé par tous les CHECK_CWRR avant.

J’ai tenté de modifier hydrol_waterbal en supprimant la pondération par vegtot, mais l’implantation de vegtot dans hydrol semble plus compliquée que prévu.

comment:3 Changed 9 years ago by jpolcher

Please be careful successful execution with CHECK_WATERBAL=TRUE does not guarantee water conservation in the model. This only verifies conservation within the hydrol.f90 module. It is indispensable to also verify water conservation in the output files of the simulation.

As far as I could see (and as can be verified in the slides I distributed to the Project-group) the model does not conserve water. So this requires more attention and this ticket. Never mind the fact that we need to agree on a common definition of veget_max/veget/vegtot first.

Please stick to English in the tickets and other documents which are accessed by all concerned by the ORCHIDEE development.

comment:4 Changed 8 years ago by peylin

  • Owner changed from somebody to aducharne
  • Status changed from new to assigned

comment:5 Changed 8 years ago by aducharne

  • Status changed from assigned to accepted

comment:6 Changed 8 years ago by aducharne

  • Resolution set to fixed
  • Status changed from accepted to closed

Correction done in rev [1118] and tested by Matthieu G. with VEGET_UPDATE=1Y over Amazonie (no crash and no water conservation problem).

Note: See TracTickets for help on using tickets.