Skip to content
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

Open
DillonJ opened this issue Apr 4, 2024 · 6 comments
Open

Simultaneous starts/shutdowns #960

DillonJ opened this issue Apr 4, 2024 · 6 comments
Labels
help / question Extra attention wanted, remove label once received Type: bug Something isn't working as expected Zone: formulation How the model is formulated

Comments

@DillonJ
Copy link
Collaborator

DillonJ commented Apr 4, 2024

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
Copy link
Collaborator

tarskul commented Apr 4, 2024

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
Copy link
Collaborator Author

DillonJ commented Apr 4, 2024

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
Copy link
Collaborator

tarskul commented Apr 4, 2024

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
Copy link
Collaborator Author

DillonJ commented Apr 5, 2024

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
Copy link
Collaborator

tarskul commented Apr 5, 2024

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
Copy link
Contributor

datejada commented Apr 5, 2024

@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.

@clizbe clizbe added Zone: formulation How the model is formulated Type: bug Something isn't working as expected help / question Extra attention wanted, remove label once received labels Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help / question Extra attention wanted, remove label once received Type: bug Something isn't working as expected Zone: formulation How the model is formulated
Projects
None yet
Development

No branches or pull requests

4 participants