Deltares
Leap years in doy cyclic timeseries
Wflow version checks
-
[X] I have checked that this issue has not already been reported.
-
[X] I have checked that this bug exists on the latest version of Wflow.
Reproducible Example
https://github.com/Deltares/Wflow.jl/blob/4becf7b1fd3dd5842ec865dbd5fbf3401039744a/src/io.jl#L1167-L1175
Current behaviour
Currently, wflow checks the length of the provided cyclic timeseries parameter. If the length is 366 then it assumes that it is always a leap year even in nonleap years. This is an issue in our forecast systems when we provide a ResFullFrac day-of-year value based on observed target levels in an operational setup, as the target volume timestamp we want to adjust is not mapped properly to the day of year fullfrac (if a 366 doy is provided in non-leap years or if we give a 365 doy in leap years). This can cause unnecessary reservoir spilling (and delays) in the short-term forecasts.
Desired behaviour
Consider combining both leap and non-leap years in cyclic doy timeseries. Perhaps an option is to map the doy from the forcing or so, and accept only 366 doy cyclic timeseries.
Additional Context
No response
After having a chat with @JoostBuitink and @atsiokanos we concluded that this is not a bug, but that the documentation can be improved on how this is internally handled. The 365-day and 366-day cyclic time series can both be used for leap and non-leap years. When a user provides a 365-day cyclic time series, the value at day (index) 59 is used for Feb. 28 and 29. The mapping between cyclic time and current model time in wflow is based on month-day tuples (e.g. (2, 28)), and this is why the assumption that day of year and index are equal is not correct. Finally, good to include in the documentation that wflow expects right forcing time stamps (at the end of a time step) while for cyclic time series time stamps this is left (at the start of a time step).
