Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#200 closed defect (fixed)

routing: pb with delsurfstor

Reported by: aducharne Owned by: jpolcher
Priority: major Milestone: IPSLCM6.v1
Component: Physical processes Version: trunc
Keywords: Cc:

Description

delsurfstor is created in routing.f90, supposedly to export the change in surface water storage (from flood, pond and lake reservoirs) (kg/m2), if we read the variable definition in the header of the routing.f90 module.

I exported this variable in a simulation with routing, no floodplains, almaouput and xios, and I get an almost continuous increase, up to more than 200000 mm in 5 years, which is not consistent with the definition !!!

I performed changes to routing, but just to add a new diagnotic, and I don't think the pb comes from my changes.

Looking at the code, delsurfstor seems based on the reservoir volumes, and not on the changes in the reservoir volumes. There also seems to conflicting calculations of the variable in hydrol_flow and hydrol_main, where the same calculation is performed twice if almaoutput...

Change History (4)

comment:1 Changed 5 years ago by aducharne

Mail de Matthieu, 30/09/15

Concernant ton problème de delsurfstor qui augmente constamment, c'est directement lié à un autre ticket pour lequel j'avais proposé une solution avec Jan mais qui n'a jamais été mergée dans le code au final. C'est le ticket 37 : https://forge.ipsl.jussieu.fr/orchidee/ticket/37

En effet, puisque tu n'actives pas les floodplains ni les ponds, ton pb vient des lacs endoréiques. Dans le code:
delsurfstor = delsurfstor + flood_diag + pond_diag + lake_diag

et aussi

lake_diag(ig) = lake_reservoir(ig)/totarea

lake_reservoir augmente constamment car l'eau n'est pas conservée dans les lacs endoréiques quand on ne met pas les swamps. Tout est expliqué dans le ticket 37.

Lien possible aussi avec le ticket 128: https://forge.ipsl.jussieu.fr/orchidee/ticket/128

comment:2 Changed 5 years ago by aducharne

Mails de AD (barre rouge) et MG:

Merci Matthieu,

il y a effectivement un lien avec T37, et c'est vrai que ce "pb" n'arrive que ponctuellement.

Mais j'ai qd meme l'impression que le pb est intensifié de manière anormale par le fait de calculer
delsurfstor = delsurfstor + flood_diag + pond_diag + lake_diag

Pour moi, la variation de volume devrait etre uniquement:
delsurfstor = flood_diag + pond_diag + lake_diag

Oui, ça me semble plutôt juste ce que tu dis...

En plus, il me semble que si almaoutput=T, on fait deux fois par pas de temps l'opération delsurfstor = delsurfstor + flood_diag + pond_diag + lake_dia

Effectivement. Je pense que c'est un bug quand on a rajouté la sortie XIOS. Le CALL send_field est précédé du calcul de delsurfstor. Ce calcul n'y était pas quand on sortait les sorties façon modipsl: le calcul était fait juste avant le histwrite de la sortie standard et avant le histwrite de la sortie haute fréquence. Du coup, maintenant, on a 2 fois le calcul. Bien vu!

comment:3 Changed 4 years ago by mguimberteau

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

The following modification has been done in [rev3537]

The resolution of the non-conservation of water in the endorheic lakes, the new diagnostic of wbr_lake [ticket #37] and the next diagnostics that will be coded for flood and pond reservoirs make the variable delsurfstor useless. It is deleted from the code.

Last edited 4 years ago by mguimberteau (previous) (diff)

comment:4 Changed 4 years ago by jgipsl

Done in the trunk rev [3537]

Note: See TracTickets for help on using tickets.