Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question Regarding Model Initialization in Calibration Period #14

Open
Nooshdokht-Bayatafshary opened this issue Sep 5, 2024 · 1 comment

Comments

@Nooshdokht-Bayatafshary
Copy link

Dear @StefaniaGrimaldi and @doc78,

I am working on improving the calibration results for my region, and I am focusing on ensuring accurate model initialization. One issue I am encountering is that the initial discharge during the calibration period is significantly higher than the observed values. I am using a 15-year prerun, and by examining the LZ time series, I can see it has reached a steady state.

While investigating further, I noticed that in the "Run" XML files generated by LISCAL, the TotalCrossSectionAreaInitValue and CrossSection2AreaInitValue keys are set to -9999, unlike other parameters such as lz, tha, thb, thc, thfa, thfb, thfc, thia, thib, and thic, which use the end file. Upon reviewing the source code, I observed that in the template.py file (line 112), the chcro and ch2cr values are not included. According to the manual, using -9999 for these two parameters means the model starts with half of the bankfull depth (https://ec-jrc.github.io/lisflood-code/3_step5_model-initialisation/)

I suspect this might be contributing to the overestimation of discharge at the start of the run. I am curious why this method is used, and why these two parameters specifically are not initialized in the same way as others in the original run.

I would appreciate any insights you could provide on this.

Best regards,
Nooshdokht

@StefaniaGrimaldi
Copy link
Contributor

Dear @Nooshdokht-Bayatafshary,

thank you for your enquiry. It is reassuring to know that, for your study area, the lower zone storage reached steady state when using a 15 years prerun.

Your analysis of the set-up of the templates for the prerun (https://github.com/ec-jrc/lisflood-calibration/blob/master/liscal/templates.py#L43) and run (https://github.com/ec-jrc/lisflood-calibration/blob/master/liscal/templates.py#L69) for model calibration is correct.

In the current version of the calibration tool, the end states of the groundwater zone (including uz) and of the soil moisture are used to initiaize the model run. Bogus values are used for chcro and ch2cr. Please note that according to these settings, the initial value of chcro is set to half bankfull, but the initial value of ch2cr is set to zero (https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/routing.py#L211).

Depending on the static input maps (more specifically, the static maps which define channels geometry: https://ec-jrc.github.io/lisflood-code/4_Static-Maps_channel-geometry/) and on the climate conditions, initializing at half bankfull conditions can lead to overestimation of discharge in the very initial months/years of the model run.

According to our experience, this problem can be removed using an adequate value of 'Spinup_days'. For reference, in the 1 arcmin European set-up and in the 3 arcmin Global set-up, 'Spinup_days' is set equal to 1095 (3 years). The use of a large value was driven by the most critical combination of channel geometry and climate conditions.

It is important to remember that the use of 'Spinup_days' also allows to adequately initialize other model states, such the the water volume in lakes and reservoirs.
Which value of 'Spinup_days' are you using?

Some time ago, we internally discussed the opportunity of using the end value of the prerun for chcro to initialize the model run. On one side, this choice could allow removing the issue of spurious large volumes in some specific contexts, on the other side, the end state of the prerun could also pick high discharge conditions (especially when modelling large domains) thus re-introducing the same issue.
We have not taken a final decision (in our experience the use of 'Spinup_days' allowed to remove the issue). In the meantime, we prioritized the implementation of an analytical solution to improve the initialization of the soil moisture states (work in progress here https://github.com/ec-jrc/lisflood-code/tree/feature/initialization). This latter improvement is expected to benefit large areas of the global domain and it will be available in the develop (and then master) branch in the upcoming months.

We hope that this answer helps,
kind regards,
Stefania

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants