reservoir_water~outgoing~observed__volume_flow_rate doesnt allow for spilling when reservoir max volume is exceeded

[michaelohanrahan]

Wflow version checks

• I have checked that this issue has not already been reported.

• I have checked that this bug exists on the latest version of Wflow.

Reproducible Example

see current behaviour, it's a simple design choice, but currently non-physical results occur.

Current behaviour

update_reservoir_outflow_obs caps outflow only by the amount of water available (storage_input), but applies no upper bound on storage:

function update_reservoir_outflow_obs(
reservoir_model::ReservoirModel,
i::Int,
boundary_vars::NamedTuple,
dt::Float64,
)
(; storage, outflow_obs) = reservoir_model.variables
(; precipitation, evaporation, inflow) = boundary_vars
storage_input = max(storage[i] / dt + precipitation - evaporation + inflow, 0.0)
outflow = min(outflow_obs[i], storage_input)
storage = (storage_input - outflow) * dt
return outflow, storage
end

Desired behaviour

Schematic should be clear that current behaviour (Red) should in reality, probably be more like desired behaviour (green) where reservoir max volume exceedance should trigger overflow/spilling like:

function update_reservoir_outflow_obs(
    reservoir_model::ReservoirModel,
    i::Int,
    boundary_vars::NamedTuple,
    dt::Float64,
)
    (; storage, outflow_obs) = reservoir_model.variables
    (; maximum_storage) = reservoir_model.parameters # Is maximum storage still in use? 
    (; precipitation, evaporation, inflow) = boundary_vars
    storage_input = max(storage[i] / dt + precipitation - evaporation + inflow, 0.0)
    outflow = min(outflow_obs[i], storage_input)
    storage = (storage_input - outflow) * dt
    if maximum_storage[i] != MISSING_VALUE
        overflow = max(0.0, (storage - maximum_storage[i]) / dt)
        storage -= overflow * dt
        outflow += overflow
    end
    return outflow, storage
end

Additional Context

No response

[vers-w]

Thanks for reporting this issue @michaelohanrahan.

This was indeed a simple design choice (to be completely independent of the reservoir type), an upper boundary on storage was not considered in an internal memo about the requirements while outflow capped by water availability was mentioned. I think it makes sense to have an upper boundary on storage for reservoir types that make use of the variable max_storage.

What are your thoughts on this @JoostBuitink (I think you were also involved in the design session for this feature)?

I guess this is also needed for v1.0, @michaelohanrahan ?

[michaelohanrahan]

Hey @vers-w , v1.0.2 is what we are working with.

Thanks for following up. Understandable that it was perhaps developed with a different case in mind, but I think we agree that exceedance of reservoir capacity should trigger some spill, in a similar way that exceeding availability at minimum operating level also changes the outflow strategy.

Looking forward to working this out.

[Starphire1]

I think this would be beneficial to implement. Spill from reservoir with abstraction would be useful for implementing wflow for more applications.

[michaelohanrahan]

Thanks for fixing what was a physical violation @vers-w ...

Wondering if this is a separate issue but since it's directly related I ask here. Interested also what you think @JoostBuitink

If we want spilling to occur once the reservoir level exceeds the spillway crest level defined in reservoir_hq (rather than only once the maximum storage volume is exceeded), is that a significant deviation in the design choice? Of course I know the answer depends on what you are trying to accomplish.

[vers-w]

If we want spilling to occur once the reservoir level exceeds the spillway crest level defined in reservoir_hq (rather than only once the maximum storage volume is exceeded), is that a significant deviation in the design choice? Of course I know the answer depends on what you are trying to accomplish.

For a reservoir using a waterlevel_discharge_curve, the maximum_storage is defined and exceedance of reservoir capacity will trigger spilling, also when using enforced observed reservoir outflows.

We discussed briefly about downstream environmental flow requirements. It is possible to set the demand parameter of the simple reservoir concept dynamically. This way it is possible to control dynamically the demand_release indirectly (based on demand and a s-curve to scale for reservoir target level). To enforce the demand_release directly with observed demand releases is not possible and considered a new feature.