LISFLOOD simulation vs in-situ

[d-andrievskaia]

Dear devs,

I'm running a one-year LISFLOOD simulation (warm start, 02/08/2023–02/08/2024) over the Rhine and comparing the results against in situ discharge at several stations. I previously ran a spin-up for 01/2021-07/2023, and I use the outputs of this spin-up as initial states for my simulation.

I noticed a consistent behaviour that I cannot explain:

• the simulation shows a noticeable deviation from the observations during approximately the first 3–4 months,
• from around December on, the simulated discharge follows the observations much more closely,
• the same behaviour is also present when I introduce a simple data assimilation with perturbed ensemble runs, suggesting that it is not caused by the data assimilation itself.

I've attached example plots illustrating this behaviour.

My questions are:

• Is this kind of early-period deviation expected after a warm start?
• Could it indicate that the model is still adjusting from its initial conditions?
• Is there anything in the initialization or forcing that you would recommend checking?

I'd appreciate any suggestions or insights.

Thank you,
Daria

[fuchsiger]

Hi Daria,

Thank you for the description and the (nice) plots and especially for using LISFLOOD :).
The behavior indeed is likely connected to the model initialization, however, maybe a few additional clarifications might be required.

In any case, I would recommend having a look at:

• LISFLOOD Initialization/Prerun: https://ec-jrc.github.io/lisflood-code/3_step4_model-initialisation/
• Cold Start & Warm Start: https://ec-jrc.github.io/lisflood-code/3_step5_model-cold-warm-start-runs/

Not sure if it the case but it's worth separating a terminology point that is easy to mix up in LISFLOOD are the spin-up and the prerun (initialization run), which are not the same thing.

• The spin-up is simply the initial transient period at the start during which the model settles from its starting conditions. It is not a separate run type but a buffer period that is excluded in the calculations of the state maps during the Initialization/prerun. It is vice versa not used/active in any non-initialization run. We usually anyway put in the cold run files as we anyway should discard the initial phase to make fully sure no spurious trends are present, so the number serves as a reminder.
• The prerun (InitLisflood=1) is a dedicated LISFLOOD run to compute long-term average flux maps, specifically lzavin (average inflow to the lower groundwater zone) and SeepTopToSubBAverage (average percolation from soil layer 2 to layer 3). These maps are then used by LISFLOOD to analytically solve for the steady-state storage of the lower groundwater zone and the third soil layer at the start of the cold start. The steady-state calculation helps to initialise the slow storages without running the model for many decades.

From your description, I am not 100% sure whether your January 2021 – July 2023 run was a regular initialization/prerun used as a spin-up but with or without the spin-up setting set? If the spin-up period and time period of the model run are the same in the init run you would end up with meaningless state maps (average fluxes). Logically, also the warm state needs properly initialized states, which seems not the case in your example. In detail, it seems the lower zone did very likely not reach steady state at the beginning of the simulation due to spurious end maps (periods too short).

More broadly, the initialization sequence is:

1. Prerun (InitLisflood=1) over a multi-year or multi-decade period to compute reliable lzavin and SeepTopToSubBAverage values. NumDaysSpinUp can be set to 1095 (3 years) to exclude this period from the flux averages. Note that a 2.5-year prerun with NumDaysSpinUp in the same range leaves essentially zero valid timesteps contributing to the average flux computation.
2. Cold start (ColdStart=1) takes the prerun outputs as input, initialises slow storages via the steady-state calculation, and sets fast storages (e.g. channel volume) to bogus values. The first ~3 years of the cold start should be discarded to allow fast storages to equilibrate. This means the scold start could/should begin 3 years before your analysis period (in your case around August 2020 at the latest, not August 2023). With that you would produce proper end maps.
3. Warm start, should only be used to resume from the end states of a converged cold start, not as a substitute for steps 1 and 2.

I think following this approach, you should remove the trend, and of course the recommended numbers from our side are just indications/starting points and are case-dependent.

If the above does not resolve the issue, it would help us to look more closely at your setup. In that case, could you share the actual model exercise/task and the settings/setup files you used.

Hope this helps & happy to discuss further once you've had a chance to check the above :).

Best regards

Timo

[d-andrievskaia]

Hi Timo,

Thank you for your quick reply! I think there has been indeed a bit (lot) of a misunderstanding :)

First of all, I'm completely new to LISFLOOD and hydrological modelling, so apologies if some of my questions are quite basic.

To clarify my current setup:

• My run covering 01/2021–07/2023 was indeed an initialization run (InitLisflood = 1). However, I did not set the NumDaysSpinUp flag because it was not present in the template I originally downloaded. I'm using LISFLOOD v4, so I wonder whether this option was introduced in v5. I also noticed that the documentation has been updated since I first set everything up, and I hadn't seen the recommendation about discarding a three-year spin-up period.
• My simulation run covers 08/2023–08/2024, with InitLisflood = 0, using the outputs of the initialization run as InitValues. From your explanation, I now understand that this corresponds to what you call a cold start.

So, if I understood correctly, I have essentially skipped one important step (the proper cold/warm start workflow), and my runs should also be longer than they currently are.

I also noticed that LISFLOOD v5 introduces an explicit ColdStart flag. Would you recommend switching to v5, or is it perfectly fine to stay with v4 and simply redo my simulations following the correct procedure? My only concern is that getting LISFLOOD running on my system took quite some time, and my project timeline is rather tight.

To make sure I understand the recommended workflow correctly, would the following be appropriate?

1. Extend the initialization run
   Instead of my current 2.5-year initialization, run it over a much longer period (for example 01/2000–08/2024). From the documentation, I understood that the initialization should ideally cover the full modelling period, including the period of interest.

2. Redo the cold start
   Run 08/2020–08/2023, using a 3-year spin-up (NumDaysSpinUp).

3. Run the warm start / experiment period
   Run 08/2023–08/2024, using the outputs of the cold-start simulation as initial conditions. This would also be the period during which I perform the data assimilation experiments.

One point I'm still unsure about: should the three-year spin-up also be discarded from the warm-start simulation, or does it only apply to the cold-start run?

I also have one additional question that has been on my mind. I thought I had found the answer in the documentation, but I'd like to confirm it with you. How important is it to save the full state maps (.nc)? So far, I have been using the end-state maps (.end.nc) to initialize the following runs, except for a few variables such as LZAvIn and Dis. I have not been saving the full state outputs because they are very demanding in terms of both storage and computation time.

I realise this is quite a few questions, but I'm still learning how the LISFLOOD workflow is intended to be used. I set everything up back in April, and although I managed to get the model running, there were still many aspects I didn't fully understand, and it now seems that some of them were quite important.

I would really appreciate your guidance.

Thank you very much for your help!

Kind regards,
Daria