Better handle carrier definitions in YAML

[Bryn Pickering]

Problem description

Moving the carrier definition component of #362 here.

We currently have a relatively complex way to handle defining carriers. Actually, it isn't complicated until we define "conversion_plus" technologies. All the complex ways of doing it are given in the docs. Ideally, we can structure this in a more coherent way, along the lines of using lists of dictionaries. Let's take a complex example and consider it from a range of angles:

cchp:
    essentials:
        name: Combined cooling, heat and power
        carrier_in: [fossil_gas, synthetic_gas]
        carrier_out: electricity
        carrier_out_2: [heat, cooling]
        primary_carrier_out: electricity
        primary_carrier_in: fossil_gas

    constraints:
        energy_eff: 0.45
        energy_cap_max: 100
        carrier_ratios.carrier_out_2: {heat: 0.8, cooling: 0.5}

a.

id: cchp
name: Combined cooling, heat and power
carriers:
    - tier: in
      carrier: [fossil_gas, synthetic_gas]
      ratios: [1, 1]
      primary: fossil_gas
    - tier: out
      carrier: electricity
      primary: electricity
    - tier: out_2
      carrier: [heat, cooling]
      ratios: [0.8, 0.5] 
energy_eff: 0.45
energy_cap_max: 100

b.

id: cchp
name: Combined cooling, heat and power
carriers:
    - tier: in
      carrier: fossil_gas
      primary: true
    - tier: in
      carrier: synthetic_gas
    - tier: out
      carrier: electricity
      primary: true
    - tier: out_2
      carrier: heat
      ratio: 0.8
    - tier: out_2
      carrier: cooling
      ratio: 0.5
energy_eff: 0.45
energy_cap_max: 100

c.

id: cchp
name: Combined cooling, heat and power
carriers:
    in:
      - carrier: fossil_gas
        primary: true
      - carrier: synthetic_gas
    out:
      - carrier: electricity
        primary: true
    out_2:
      - carrier: heat
        ratio: 0.8
      - carrier: cooling
        ratio: 0.5
energy_eff: 0.45
energy_cap_max: 100

d.

id: cchp
name: Combined cooling, heat and power
carriers:
    in:
      - tier: 1
        carrier: fossil_gas
        primary: true
      - tier: 1
        carrier: synthetic_gas
    out:
      - tier: 1
        carrier: electricity
        primary: true
      - tier: 2
        carrier: heat
        ratio: 0.8
      - tier: 2
        carrier: cooling
        ratio: 0.5
energy_eff: 0.45
energy_cap_max: 100

Since the 'carrier tiers' (in, out, in_2, out_2, etc.) are going to be dimensions of the dataset, c/d might work best (i.e. explicit keys for the carrier tiers). However, to work with loading data from tabular form (#92), limited nesting would be ideal.

Irrespective of how we approach the problem, ratios are still somewhat difficult to wrap one's head around. They link tiers > 1 to tier == 1 (e.g. carrier_prod[heat] / carrier_prod[electricity] == 0.8), but this isn't clear from their definition.

[Bryn Pickering]

Thoughts on naming:

• tier -> stream_group or stream to try and link it with the idea of rivers that can come from several sources and split into several flows downstream. Within a single stream there would be the option to have the model decide how much to rely on different energy carriers, hence stream_group.
• ratio: ratio_to_stream_1 or more verbose prod_compared_to_stream_1_prod (and the same for con)

[fvandebeek]

Hi Bryn,

Working with Calliope for some time now, I'd personally prefer option b or c

Working with the "[x,y]" can be quite confusing. Also, sticking to "in" or "out" for the "tier" parameter is most clear I think.

Linked to this topic, would it be possible to allow for cost definitions per carrier as well? Currently it is all linked to the primary carrier, right? It would be very helpful if the user can assign individual om_prod/om_con costs to specific carriers, based on the same carrier_ratio logic.

Floris

[Bryn Pickering]

Fix introduced in #518 that will also allow you @fvandebeek to define costs per carrier in/out.

Ended up moving away from the idea of carrier "tiers"/"streams" as they can get confusing. Instead, we can leverage the new custom math API to the same effect. See #484 for more info (and, soon, the documentation).