Clarify the role and importance of ``unmet_demand`` about calliope HOT 5 CLOSED

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

from calliope.

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.

from calliope.

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)

from calliope.

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'

from calliope.

Addressed as of 8bdce5b

from calliope.