New reserves design

[manuelma]

Introduction

The purpose of this post is to present the new SpineOpt's reserves design and compare it to the current implementation. The ultimate goal is to allow for a more clear appreciation of the benefits and drawbacks and also to help the development work.

@gnawin @datejada @g-moralesespana @mihlema @DillonJ @nnhjy

Design

Variables

name	description
nonspin_units_started_up	number of units held for non-spinning upwards reserve provision
nonspin_units_shut_down	number of units held for non-spinning downwards reserve provision

Parameters

name	description
is_reserve_node	whether a node's demand should be interpreted as a reserve requirement
upward_reserve	whether the requirement is for upwards reserve
downward_reserve	whether the requirement is for downdwards reserve
is_non_spinning	whether the requirement is for non-spinning reserve
reserve_procurement_cost	additional cost associated to reserve flows
minimum_reserve_activation_time	see constraint below

Constraints

The above parameters don't trigger constraints on their own but rather add terms to some constraints so as to do something special with reserve flows.

Unit minimum operating point (done)

See #742

Unit flow capacity (done)

See #786

Ramp up and down (done)

See #789

Non-spinning reserve flows within limits (done)

minimum_operating_point(unit=u) * nonspin_units_started_up[u]
<=
sum(unit_flow[i...] for i in unit_flow_indices(unit=u) if is_reserve_node(i.node))
<=
start_up_limit(unit=u) * nonspin_units_started_up[u]

for u in unit()

minimum_operating_point(unit=u) * nonspin_units_shut_down[u]
<=
sum(unit_flow[i...] for i in unit_flow_indices(unit=u) if is_reserve_node(i.node))
<=
shut_down_limit(unit=u) * nonspin_units_shut_down[u]

for u in unit()

Connection flow capacity (only in the current implementation, to review)

For some reason we subtract backward non-reserve flows on the lhs.

connection_flow[some direction, all nodes] - connection_flow[opposite direction, non-reserve nodes]
<=
connection_capacity(direction=some direction) * (candidate_connections or 1)

Minimum reserve activation time (only in the current implementation, to review)

If a storage provides reserves to a reserve node, one needs to ensure that the storage state is sufficiently high to provide these scheduled reserves at least for the duration of the minimum_reserve_activation_time.
This constraint doesn't have a unit-test, the below is extracted directly from code and slightly simplified.

node_state[storage_node, t - 1]
>=
node_state_min[storage_node, t]
+ sum(
	unit_flow[u, to reserve_node, t] * minimum_reserve_activation_time(node=reserve_node) / duration(t)
	for reserve_node in indices(minimum_reserve_activation_time)
	for u in unit__from_node(node=storage_node)
	if unit__to_node(unit=u, node=reserve_node)
)

for storage_node in node()
if has_state(node=storage_node)

Objective

Cost of reserve procurement (already in the current implementation)

... + {reserve_}unit_flow * reserve_procurement_cost + ...

[manuelma]

@g-moralesespana @datejada @gnawin is the above right? More specifically, do we want to keep the objective term in the new design? Do we want to keep the minimum reserve activation time constraint? What about the treatment of reserves in the connection capacity constraint, do you agree with that formulation? What changes are needed?

@mihlema can you perhaps validate what I wrote about the min reserve activation time constraint? And maybe clarify why we are subtracting non-reserve flows in the opposite direction from the lhs in the connection flow capacity constraint?

Cc @nhniina @DillonJ @jkiviluo @nnhjy

[nhniina]

I would like to keep the minimum reserve activation time constraint. But I think we should rename the parameter as well as add another one (unless that's done already - you mention that the constraint above is a simplified version)

• minimum_reserve_activation_duration: how long the reserve should be provided once activated
• reserve_reactivation_time: how soon the unit providing reserve needs to be able to reactivate after the start of the previous activation

The duration parameter should then be divided by the reactivation time parameter in the constraint.

In addition, I think that we should also consider that reserve provision doesn't violate storage state max bound.

[manuelma]

Hi @nhniina - thank you for that - I was hoping not to add any new requirements in this dicussion but just refine/agree on the current requirement so I can implement it as soon as possible. Is it ok if we skip your suggestion for now and work on it in a separate issue?

What do others think?

[nhniina]

Yes, it's ok to skip the suggestion for now and also to drop the whole constraint for now. I'm actually also confused why we divide reserve provision * minimum reserve activation time by the duration of the time step. Shouldn't we multiply it by the step duration? So yes, would be good to hear opinions from others as well.

[g-moralesespana]

@nhniina I'm actually also confused why we divide reserve provision * minimum reserve activation time by the duration of the time step. Shouldn't we multiply it by the step duration? So yes, would be good to hear opinions from others as well.

where do you see that? I also do not understand this part:

The duration parameter should then be divided by the reactivation time parameter in the constraint.

are there eqs somewhere showing how the activation time enters in a constraint?

[nhniina]

In the minimum reserve activation time constraint, this line

unit_flow[u, to reserve_node, t] * minimum_reserve_activation_time(node=reserve_node) / duration(t)

I'm probably causing confusion because I talk about two duration parameters: the time step duration duration(t) and then the minimum_reserve_activation_time which I would like to rename to minimum_reserve_activation_duration. As discussed in the call, reserve activation time is a different thing. We need to think whether that (or its maximum) should be considered in the constraint as well.

[manuelma]

There is one design question that touches the data structure and I think we need to figure out together. How do we tell the model that a unit provides regular flows and reserve flows?

At the moment, we need to create a node group including the regular node and the reserve node, and then create a unit__to_node between the unit and the group. This has the advantage that one can define unit_capacity for this unit__to_node (between the unit and the group) and this constrains the sum of the regular and the reserve flows.

So I am inclined to keep this design now. At some point I thought it was awkward, and that some sort of node__node relationship between the regular and the reserve node would be better - but now I am thinking the group is nice.

Anyways, I don't think we need to decide right now. We can keep the group for now and decide later.

Any thoughts @DillonJ @mihlema @jkiviluo @g-moralesespana?

[manuelma]

The connection flow capacity and the minimum reserve activation time won't be touched for now, although we need to review them.

The plan is to review the first with @mihlema, and the second as part of a new proposal involving reserves with activation time to be prepared by TNO (@g-moralesespana, @datejada, @gnawin).

Does that sound good?

[g-moralesespana]

This is for the storage, right?

[manuelma]

Yeah, the one for the storage. So there is a storage connected to a unit connected to a reserve, and the storage level needs to be high enough so the reserve can be activated in time. Not sure how that's gonna look but if you could write it in math, I can try and implement it. Or, if it doesn't make sense at all we just get rid of it.

[datejada]

@manuelma, we at TNO have discussed this topic, and @g-moralesespana will write the constraints for the storage. We will keep you posted!

[manuelma]

Thank you! Just in case you missed it, there is also this question here (no rush, just a heads up) #796 (comment)

[g-moralesespana]

@manuelma I just posted the formulation in Overleaf https://www.overleaf.com/project/6454fde7fdf7f1c73ceeb2a0. Hope it is clear, otherwise, I can document it further.