Changes in the new ramp design

[manuelma]

Introduction

The purpose of this post is to present the current SpineOpt's ramp implementation and then the changes introduced by the new design. 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

Common stuff

This stuff is required by the current and/or the new implementations (but none of them introduces it).

Variables

name	description
unit_flow	flow on a unit
units_on	number of units online
units_started_up	number of units started up
units_shut_down	number of units shut down
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
minimum_operating_point	lower bound on the unit's flow

Current implementation

Parameters

name	description
ramp_up_limit	upper bound on the unit's ramp up flow
ramp_down_limit	upper bound on the unit's ramp down flow
min_startup_ramp, max_startup_ramp	lower and upper bound on the unit's startup flow
min_shutdown_ramp, max_shutdown_ramp	lower and upper bound on the unit's shutdown flow
min_res_startup_ramp, max_res_startup_ramp	lower and upper bound on the unit's non-spinning startup flow
min_res_shutdown_ramp, max_res_shutdown_ramp	lower and upper bound on the unit's non-spinning shutdown flow
ramp_up_cost, ramp_down_cost	costs associated to ramp up and down flows

Variables

name	description
ramp_up_unit_flow	unit's ramp up flow
ramp_down_unit_flow	unit's ramp down flow
start_up_unit_flow	unit's startup flow
shut_down_unit_flow	unit's shutdown flow
nonspin_ramp_up_unit_flow	unit's non-spinning startup flow
nonspin_ramp_down_unit_flow	unit's non-spinning shutdown flow

NOTE: These variables are not generated unless they are used.

Constraints

Ramp up and down flows within the limits

ramp_up_unit_flow <= (units_on - units_started_up) * ramp_up_limit

ramp_down_unit_flow <= (units_on - units_started_up - nonspin_units_shut_down) * ramp_down_limit

NOTE: It feels that we should also subtract nonspin_units_shut_down to units_on on the rhs of the first constraint
to make it more symmetrical to the second constraint, but I'm just guessing...

Start up and shut down flows within the limits

units_started_up * min_startup_ramp <= start_up_unit_flow <= units_started_up * max_startup_ramp

units_shut_down * min_shutdown_ramp <= shut_down_unit_flow <= units_shut_down * max_shutdown_ramp

Non-spinning ramp up and down flows within the limits

nonspin_units_started_up * min_res_startup_ramp <= nonspin_ramp_up_unit_flow <= nonspin_units_started_up * max_res_startup_ramp

nonspin_units_shut_down * min_res_shutdown_ramp <= nonspin_ramp_down_unit_flow <= nonspin_units_shut_down * max_res_shutdown_ramp

Split ramps

+ unit_flow[t] - unit_flow[t-1]
+ unit_flow[t, upward_reserve] - unit_flow[t, downward_reserve]
==
+ ramp_up_unit_flow[t] + start_up_unit_flow[t] + nonspin_ramp_up_unit_flow[t]
- ramp_down_unit_flow[t] - shut_down_unit_flow[t] - nonspin_ramp_down_unit_flow[t]

Objective

... + ramp_up_unit_flow * ramp_up_cost + ramp_down_unit_flow * ramp_down_cost + ...

New design

Parameters

name	description
ramp_up_limit	upper bound on the unit's ramp up flow
ramp_down_limit	upper bound on the unit's ramp down flow
startup_limit	upper bound on the unit's startup flow (spinning or not)
shutdown_limit	upper bound on the unit's shutdown flow (spinning or not)

Variables

No new variables.

Constraints

Ramp up flow within the limits

+ unit_flow[t] - unit_flow[t-1] + unit_flow[t, upward_reserve]
<=
+ (startup_limit - minimum_operating_point - ramp_up_limit) * units_started_up[t]
+ (minimum_operating_point + ramp_up_limit) * units_on[t]
- minimum_operating_point * units_on[t-1]

Ramp down flow within the limits

+ unit_flow[t-1] - unit_flow[t] + unit_flow[t, downward_reserve]
<=
+ (shutdown_limit - minimum_operating_point - ramp_down_limit) * units_shut_down[t]
+ (minimum_operating_point + ramp_down_limit) * units_on[t-1]
- minimum_operating_point * units_on[t]

Objective

No new objective terms.

Changes

1. Get rid of all the lower bound parameters, min_startup_ramp, min_shutdown_ramp, min_res_startup_ramp, min_res_shutdown_ramp; we just need minimum_operating_point.
2. Get rid of max_res_startup_ramp and max_res_shutdown_ramp parameters; instead, use max_startup_ramp and max_shutdown_ramp also for the non-spinning reserve flows - but rename these parameters to startup_limit and shutdown_limit.
3. Get rid of all the current ramp variables.
4. Get rid of all the current constraints and just replace them by the new constraints (not enough overlapping).
5. Get rid of the current ramp objective terms.

[manuelma]

Can anybody please confirm that the above is correct and we are all onboard with the changes? It seems like the new design trades some of the flexibility by simplicity - maybe that's good, I don't know. The lack of ramp costs in the new design is more concerning, maybe we want to introduce them? The difficulty then is we do not have the dedicated ramp up/down flow variables to write the objective function...

[datejada]

@g-moralesespana, @gnawin, and I will discuss today how to cover the last two cases (the two first ones are covered with the current formulation. We want to double-check the RHS of the constraints for these cases, and then we will get back with a proposal and discuss how it can be implemented in SpineOpt.

[manuelma]

Thank you very much @nhniina for the explanation. And thank you @datejada for the update, sounds like a plan, very good.

[g-moralesespana]

To generalize the reply of @nhniina, we need to consider more constraints affecting the 4 cases:

• unit output, ramp up & upper bound unit capacity constraints, upward reserve provision
• unit output, ramp down & lower bound unit capacity constraints, downward reserve provision
• unit input, ramp up & upper bound unit capacity constraints, downward reserve provision
• unit input, ramp down & lower bound unit capacity constraints, upward reserve provision

and the logic for nonspinning reserve:

• unit output, uptime & upper bound constraints, nonspinning_unit_shutdown
• unit output, downtime constraints, nonspinning_unit_startup
• unit input, uptime & upper bound constraints, nonspinning_unit_startup
• unit input, downtime constraints, nonspinning_unit_shutdown

[manuelma]

Sounds good @g-moralesespana - just to understand, there will be changes to more constraints than just the ramp constraints? It would be good to specify those changes with respect to the overleaf document https://www.overleaf.com/project/6454fde7fdf7f1c73ceeb2a0 - maybe highlight the new terms in red or something. I can work on that in a new PR.

[datejada]

We continue the discussion for consumption units providing reserves here: #796

[nnhjy]

So the following variables will remain in the new implementation concerning that:

No new variables.

and

3. Get rid of all the current ramp variables.

Is that correct?

Common Variables

name	description
unit_flow	flow on a unit
units_on	number of units online
units_started_up	number of units started up
units_shut_down	number of units shut down
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

Specific Variables

name	description
start_up_unit_flow	unit's startup flow
shut_down_unit_flow	unit's shutdown flow

[manuelma]

No, sorry, start_up_unit_flow and shut_down_unit_flow will also be gone - I included them in the 'current ramp variables' because they only serve the current ramp implementation and nothing more.

[manuelma]

Since nobody seems to complain I think it's time for us to finally try and implement these changes. If you are ok @gnawin @datejada I can take the first stab, seems pretty straightforward since it's mostly getting rid of old stuff and adding new stuff (no code transformation so to say.)

I can work on a new branch and publish as soon as possible. Maybe I can write the code and you @gnawin can write the tests, does that sound ok?

[gnawin]

Sure. Thank you very much for the work @manuelma. Once the constraint is finished, I will take a shot at the tests.

[manuelma]

Hi @gnawin

I opened a draft PR with the ramp changes #789

My part is basically done, all tests pass except the ones for the ramp up and down constraints, which are the ones I was hoping you could fix (but I could do it too if you are short on time)...

[gnawin]

Hi @gnawin

I opened a draft PR with the ramp changes #789

My part is basically done, all tests pass except the ones for the ramp up and down constraints, which are the ones I was hoping you could fix (but I could do it too if you are short on time)...

Hi @manuelma,

It was my initial idea to write this test as well. But since your part is already done, and I have not started fully on the other test (for the unit capacity), time-wise, it will be most favorable if you can do this now.

Meanwhile, I will try my best on the other one, but it may be not ideal in case it takes too long (either because I'm stuck somewhere and/or I'm short of time) and you're already on top of this. Will keep you closely posted on my progress, and say if I can't finish it this week I'll hand it to you. Does that sound okay?

[DillonJ]

Hi folks,

Not sure if this is the right place to comment - but we just had a discussion on ramp rates and there was an issue where the actual ramp rate in the old formulation depended on the temporal resolution of the unit_flow variable. That is one issue. A second issue is that if the temporal changes over time, as it can and as we support, then the effective ramp rate changes too which would not be expected behaviour.

For example - we have models that have a low resolution look-ahead for long term storage and if a ramp rate was imposed, this would likely lead to infeasibilities. I think we need to make sure of three things:

1. The effective ramp rate shoud take account of the duration of timeslices and account for changes in temporal resolution correctly
2. The name of the ramping parameters should be explicit regarding the assumed temporal units. This is an exception in SpineOpt where data usually defines units - but in cases regarding duration, we need to be explicit.
3. The naming of the parameters should make it clear that the value is relative to the unit_flow capacity. E.g. relative_ramp_up_limit_per_hour (or something like that).

[manuelma]

Good points @DillonJ

My impression is we handle the above by multiplying relevant terms in the constraint by the duration of the corresponding time slice. That means the ramp value is relative to the model's duration_unit which to me makes a lot of sense, but we need to write it down in the documentation of all the ramp parameters. In other words, clarify that they are both relative to the capacity and to the duration unit of the model.

I will write unit-tests too to verify that the behavior meets the above points.

Regarding naming, we have ramp_up_limit and ramp_down_limit which I think might work. Personally I'd prefer to clarify the meaning in the documentation rather than having a longer self-explanatory name, but I'm open.

[datejada]

Thank you @manuelma, I agree with your answer to @DillonJ

[jkiviluo]

Right, the unit should be p.u. / min (or another time unit).

While I think the names should be descriptive, I also think it's enough in this case to have ramp_up_limit and then start the parameter description with the unit. relative is often difficult to interpret - it's not obvious what the thing is relative to.

[DillonJ]

The main thing is that it is clear, at least in the documentation, about how the parameter is used and how it is interpreted from a temporal resolution point of view - so the implementation is sensible in that regard.

I think it's probably fine that we make it relative to the model duration unit - but a user might not be familiar with that or its implications so in the documentation relating to ramp_up/down_limit, we should say what the default is as in the vast majority of cases, a user won't have changed it.

[g-moralesespana]

@DillonJ and @manuelma I agree that the ramp should be multiplied by the duration of the current time slice, which also means it can change per time slice if the duration of the time slice changes.

[manuelma]

I have one more question here @gnawin @datejada @g-moralesespana

The new contraints do not consider the variables nonspin_units_started_up and nonspin_units_shut_down - is that intended? Don't we need to consider non-spinning reserve provision as well in the context of start_up_limit/shut_down_limit?

[manuelma]

Thank you @g-moralesespana - so it is handled in other constraints.

[jkiviluo]

Below is a comment of mine in a previous discussion about reserve formulations. I think it's still relevant. Although maybe doesn't need to impact what's going on in this issue at this stage, but maybe just a further evolution - I think it's impact would be mostly on the data side. Including dropping the name 'non-spinning', because it's inadequate.

• I don’t particularly like the distinction between spinning and non-spinning. It should be about reaction time. Sometimes that reaction time is limited by start-ups and sometimes you can have a reaction time even though the unit is ‘online’. This could be due to e.g. communication delay or valves. The reaction time can prevent some resources from contributing to all reserve categories. It all can probably be represented on the data side before applying the equations.

[manuelma]

Thank you @jkiviluo that's interesting. So you suggest dropping those two variables altogether?
Anyways that discussion belongs to the reserves I believe. My plan is to open a new discussion similar to this one but about the reserves so we can look at those details.

[g-moralesespana]

I completely agree with @jkiviluo, the reserves are products that are demanded in different time frames, it does not matter that much if they are spinning and not spinning. I think we can move on with this topic. And as @manuelma proposed, it is better to open a new discussion about this. Anyway, the formulation is (almost) the same but some names should change.

[manuelma]

Here is the discussion about reserves #795

Although, I feel that moving away from spinning/non-spinning might be better done in a second round. I suggest we first get it right with spinning/non-spinning and then we generalize into 'speed' - otherwise the change might become too overwhelming.

[manuelma]

Hi @manuelma, thanks for pointing this out. Indeed a tighter constraint for ramp down limit is:

Quick question @g-moralesespana - the term in red above is a mistake, right? You corrected it in a comment in this discussion but the overleaf (where the equation is numbered as 11) still has it, see here https://www.overleaf.com/project/6454fde7fdf7f1c73ceeb2a0

[g-moralesespana]

Yes, it is a mistake. I just corrected the overleaf. Sorry again for the confusion.