Starttime #262
Starttime #262
Conversation
The model starttime was defined 1 timestep ahead of the actual current model time, e.g.: after model initialization (Δt = 86400.0 s) with a model state time of 2000-01-01, the current model time was set at 2000-01-02. And during a simulation the current model time stayed 1 timestep ahead. This has changed: the starttime (also in the TOML file) is the model state (cold or warm) time, and the current model time reflects now the actual current model time. This time handling is also easier to interpret for users running a wflow model via BMI.
by removing subtraction of model timestep Δt from the first NetCDF time, for a standalone Wflow run this is also fine.
With clock advancement, loading forcing, updating model and optional writing of model output (removed from model `update` function). This function is also called from BMI.
|
Thanks for this work! I am (once again ;) ) a little bit confused about the handling of time, see the figure below. Here I ran the same model, but the timeseries are shifted by 1 timestep. I don't think this the expected behavior right? In this case the If the first forcing timestep is set to 2008-01-02, I would expect that the first output of Wflow to also be at 2008-01-02 (as the timestep 2008-01-01 are represented by the instates). When specifying a
|
Yes, when the |
Change `starttime` from forcing.nc: first timestep in forcing.nc minus 1 model timestep, so the first forcing timestep is included in the Wflow run. For a `fews_run` the `starttime` is equal to the first forcing timestep (first forcing timestep is excluded).
The
starttimewas defined one model timestepΔtahead of the actual model time (the initial conditions timestamp (state time)). As a consequence this was also the case for the current model time. To allow for an easier interpretation of Wflow time handling, either through BMI or directly, thestarttimeis now equal to the state time, resulting in current model times without an offset.