Add constraint to avoid simultaneous starts/shutdowns

[DillonJ]

Currently, there is nothing preventing simultaneous starts and shutdowns and if there are no start costs, this is seen. It's also used by the model to avoid the ramp_up/down_limit if start_up/shut_down_ramp_limit are not specified.

Are we missing a constraint along the lines of units_started_up + units_shut_down <= units_available?

@datejada @jkiviluo?

[tarskul]

Is there a particular reason to use start up / shut down variables without using the minimum up / down time constraints (which would also avoid your simultaneous use of start up and shut down)?

[DillonJ]

The particular use case is a gas system... and using min up and down times to achieve the same resutriction as units_started_up + units_shut_down <= units_available is a lot more expensive

[tarskul]

If there is no mut/mdt or start cost, what are the start up / shut down variables used for? Is it simply used as a flow variable? In that case should they then simply be removed from your formulation? Then you would still have to limit your flow loops but that typically happens with efficiency or cost.

[DillonJ]

The formulation should work. There are plenty of scenarios where there would be no min up/down times but where starts are meaningful. E.g. flexible OCGT units with min load and idle heat rate.

[tarskul]

Right, part-load efficiency, forgot about that one. I always find it difficult to see the formulation if I don't have it in front of me.

Then it would be fair. But, units available is in part equal to number of units. Doesn't that mean that your proposed constraint is fairly similar to having an artificial mut of 1 time step? (or does mut trigger other unnecessary constraints as well? I'm still not too familiar with what constraint gets triggered from which parameters)

[datejada]

@DillonJ I suggest you define a minimum up and down time of 1 unit of time (e.g., 1 hour). German's tight and compact formulation works for this case, and I'm confident it will avoid starting up and shutting down simultaneously. In addition, it is a fair assumption, even for very flexible OCGTs, which, as fast as they are, will be at least 1 unit of time up/down in the unit commitment scheduling.

[datejada]

Conclusion of the discussion: Add a constraint units_started_up + units_shut_down <= units_available + investment_units

• This constraint will prevent simultaneous starts/shutdowns if the RHS is 1
• For a value of the RHS>1 (i.e., cluster units), we add a warning that simultaneous starts/shutdowns can't be avoided with this constraint. Adding a minimum up and down time of 1 unit will prevent this behaviour.

[datejada]

After discussion with @g-moralesespana we should not add this constraint because it is worse for the MIP. The minimum up/down time should be set by default to 1 always to ensure non-simultaneous start-ups and shutdowns (even in the clustered unit commitment case).

@manuelma What is the best way to achieve that default? We can change the template but only want to create the constraints if the startup and shutdown variables are created. Any ideas? So I can try to implement them in the code. Thanks!

[DillonJ]

See my comments here https://github.com/spine-tools/SpineOpt.jl/pull/1092

Does this work with temporal resolution greater than 1h?

We have models with units with min up/down times of 15 minutes

We probably can't make any safe assumption about what the default min up/down time should be - unless we process the temporal structure and do something like set it to the duration of the highest resolution timeslice which might be different for each unit

[g-moralesespana]

@DillonJ see my reply in #1092, the solution works for all the cases you mention.

[DillonJ]

Thanks @g-moralesespana - then selection of the default is the question

[g-moralesespana]

Yes, the default should be one period, independently from the resolution chosen, so that would always work.

[jkiviluo]

It feels to me like this shouldn't be about the min/up down time value set by the user or by the default. The constraint between two consecutive timesteps should be triggered when there is an online unit. If the min/up time (from the default or by the user) is longer than the length of two timesteps, then that should of course replace the constraint duration.

[g-moralesespana]

@jkiviluo I could not follow you ;). Since the default of the minimum up/down time seems to be an issue, especially for different durations. Something in the line of what @jkiviluo, to avoid the simultaneous startup/shutdown, is to add the following two constraints: unit_started_up <= unit_on (2) unit_shut_down <= 1 - unit_on (3) But, if there is a minimum up/down time defined, we just add the minimum up/down constraints and deactivate (2) and (3), since (2) and (3) will be become redundant because they are dominated by the minimum up/down constraints, which also avoid simultaneous startup/shutdown.

[jkiviluo]

I just meant the same thing you said in your previous comment - trying to reply to Jody's question how to select the default.

We don't need to worry about the default, since, independent of the default, we should have 1 timestep min up/down times (but just for units that have online variables of course).

[g-moralesespana]

Nice and agree, so I got your comment after all :)