-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simultaneous starts/shutdowns #960
Comments
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)? |
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 |
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. |
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. |
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) |
@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. |
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?
The text was updated successfully, but these errors were encountered: