Technologies (techs
)¶
The techs
section in the model configuration specifies all of the model's technologies.
Calliope allows a modeller to define technologies with arbitrary characteristics by defining one of the abstract base techs as base_tech
.
This establishes the basic characteristics in the optimisation model (decision variables and constraints) applied to the technology:
supply
: Draws from a source to produce a carrier.demand
: Consumes a carrier to supply to an external sink.storage
: Stores a carrier.transmission
: Transmits a carrier from one node to another.conversion
: Converts from one carrier to another.
Sharing configuration through inheritance
To share definitions between technologies and/or nodes, you can use configuration inheritance (the inherit
key).
This allows a technology/node to inherit definitions from tech_group
/node_group
definitions.
Note that inherit
is different to setting a base_tech
.
Setting a base_tech does not entail any configuration options being inherited.
It is only used when building the optimisation problem (i.e., in the math
).
The following example shows the definition of a ccgt
technology, i.e. a combined cycle gas turbine that delivers electricity:
ccgt:
name: 'Combined cycle gas turbine'
color: '#FDC97D' # (1)!
base_tech: supply
carrier_out: power
source_use_max: .inf # (2)!
flow_out_eff: 0.5
flow_cap_max: 40000 # kW
lifetime: 25
cost_interest_rate:
data: 0.10 # (3)!
index: monetary
dims: costs
cost_flow_cap:
data: 750 # USD per kW
index: monetary
dims: costs
cost_flow_in:
data: 0.02 # USD per kWh
index: monetary
dims: costs
- This is an example of when using quotation marks is important. Without them, the colour code would be interpreted as a YAML comment!
- the period at the start of
.inf
will ensure it is read in as afloat
type. - Costs require us to explicitly define data in the indexed parameter format so that we can define the cost class (in this case:
monetary
).
Each technology must specify an abstract base technology and its carrier (carrier_out
in the case of a supply
technology).
Specifying a color
and a name
is optional but useful when you want to visualise or otherwise report your results.
The rest of the data for the technology is used in the optimisation problem: to set constraints and to link the technology to the objective function (via costs).
In the above example, we have a capacity limit flow_cap_max
, conversion efficiency flow_out_eff
, the life time (used in levelised cost calculations), and the resource available for consumption source_use_max
.
In the above example, the source is set to infinite via inf
.
The parameters starting with costs_
give costs for the technology.
Calliope uses the concept of "cost classes" to allow accounting for more than just monetary costs.
The above example specifies only the monetary
cost class, but any number of other classes could be used, for example co2
to account for emissions.
Additional cost classes can be created simply by adding them to the definition of costs for a technology.
Costs in the objective function
By default, all defined cost classes are used in the objective function, i.e., the default objective is to minimize total costs.
Limiting the considered costs can be achieved by customising the in-built objective function to only focus on e.g. monetary costs ([monetary] in costs
), or updating the objective_cost_weights
indexed parameter to have a weight of 0
for those cost classes you want to be ignored, e.g.:
Transmission technologies¶
You will see in nodes
page that you make it possible for investment in technologies at nodes by specifying the technology name under the node key.
You cannot do this with transmission technologies since they span two nodes.
Instead, you associate transmission technologies with nodes in techs
:
- The region you specify in
from
orto
is interchangeable unless you set the parameterone_way: true
. In that case, flow along the transmission line is only allowed from thefrom
region to theto
region.
Understanding tech-level parameters¶
Required parameters¶
There are required parameters according to the technology base_tech
:
supply
:base_tech
andcarrier_out
.demand
:base_tech
andcarrier_in
.storage
:base_tech
andcarrier_out
andcarrier_in
.transmission
:base_tech
andcarrier_out
,carrier_in
,to
, andfrom
.conversion
:base_tech
andcarrier_out
andcarrier_in
.
For storage
and transmission
, it may seem like unnecessary repetition to define both carrier_out
and carrier_in
as they are likely the same value.
However, doing so makes it much easier to process your model definition in Calliope!
Inbuilt parameters¶
There is a long list of inbuilt parameters that we use in our base math. These are listed in full with descriptions and units in our model definition reference page. These parameters come with strict types, default values, and other attributes used in internal Calliope processing. Therefore they should always be your first port of call. However, if you want to add your own parameters, that is also possible.
Adding your own parameter¶
You can also add any new parameter you like, which will then be available to use in any custom math you want to apply. The only requirements we apply are that it cannot start with an underscore or a number.
We also have a check for any parameter starting with cost_
.
These must define a cost class.
Using the indexed parameter format¶
The indexed parameter format allows you to add dimensions to your data.
By defining just a data value, the resulting parameter will only be indexed over the techs
dimension (+ optionally the nodes
dimension if you provide a new value for it at a node).
By using the indexed parameter format, you can add new dimensions.
We saw this above with costs
, but you can add any dimension except nodes
.
Examples
techs:
tech1:
source_use_equals:
data: [15, 5]
index: ["2005-01-01 12:00:00", "2005-01-01 13:00:00"]
dims: timesteps
(De)activing techs¶
In an override you may want to remove a technology entirely from the model.
The easiest way to do this is to set active: false
.
The resulting input dataset won't feature that technology in any way.
You can even do this to deactivate technologies at specific nodes and to deactivate nodes entirely.
Conversely, setting active: true
in an override will lead to the technology(/node) reappearing.
Note
When deactivating nodes, any transmission technologies that link to that node will also be deactivated.