#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 7 years ago by aducharne
comment:2 Changed 7 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 7 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.
comment:4 Changed 7 years ago by jgipsl
Done in the trunk rev [3537]
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