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

Clarify the role and importance of unmet_demand #21

Closed
sjpfenninger opened this issue Oct 13, 2016 · 5 comments
Closed

Clarify the role and importance of unmet_demand #21

sjpfenninger opened this issue Oct 13, 2016 · 5 comments

Comments

@sjpfenninger
Copy link
Member

No description provided.

@sjpfenninger sjpfenninger added this to the 0.4.0 milestone Oct 13, 2016
@sjpfenninger sjpfenninger modified the milestones: 0.5.0, 0.4.0 Nov 22, 2016
@sjpfenninger
Copy link
Member Author

Possible pre-processing step: add up all e_cap.max and compare against peak demand -- warn if there is an obvious issue with capacity

@brynpickering
Copy link
Member

An intermediate step is to put this as a switch in model.yaml (True/False) such that all carriers are either assigned an unmet_demand or not. This saves the user adding this into their technology and location files, adding the unmet_demand technologies instead during pre-processing.
Ideally this would go one step further by checking maximum possible production vs. demand at each time step during pre-processing, adding unmet_demand only if there is obviously going to be an issue with meeting demand.

@GraemeHawker
Copy link
Contributor

It's clear that for a least cost optimisation unmet_demand should have a high cost (which may or may not be related to VoLL)- but the behaviour for non-monetary cost classes is not so clear. If auto-generating unmet_demand, should this auto-apply a default (e.g.) om_var: 1.0e6 cost for all cost classes?

(For example, if doing a least emissions optimisation, optimal case is to build nothing and meet no demand as there are no emissions if there is no energy generated. But putting in a high emissions cost for unmet_demand seems unreflective of reality. The correct way would be to have a user objective function that minimises emissions alongside a security constraint, or to use a weighted objective function)

@brynpickering
Copy link
Member

Agreed that it should cover all cost classes, or perhaps more importantly apply an arbitrarily high abstract cost to the objective function without the user ever seeing it. My preference would be to have a decision variable called 'unmet_demand' which is indexed over locations, carriers, and timesteps (as is required for system balance). It is applied directly in the system balance constraint and the user never defines it. Then, in the objective function this unmet_demand value is multiplied by our big M to provide the barrier to its use. It is thus independent of cost types and we avoid the confusion of unmet_demand being a 'technology'

@sjpfenninger sjpfenninger self-assigned this Mar 6, 2018
@sjpfenninger
Copy link
Member Author

Addressed as of 8bdce5b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants