Explicit links

[timtroendle]

Problem description

The current way of modelling links has some issues:

1. There are loads of link technologies, which makes analysing results complicated and which often requires special case treatment (for example in halving link capacities).
2. Building a network model of Calliope results is rather difficult.

Instead, it would probably good to model links explicitly (potential example in the Pyomo doc).

Calliope version

0.6.5

[brynpickering]

Linking with #326 and #362, we could use lists of dicts to define links, e.g.:

from:

links:
    X1,X2:
        techs:
            power_lines:
                distance: 10

to:

links:
    - id: my_link # (this *could* be optional)
      from: X1
      to: X2
      link_techs:
        - id: power_lines
          distance: 10

Since transmission technologies are their own beast, having them defined under a top-level key link_techs might not be a bad idea. I think @sjpfenninger has some more he can add on this from an offline discussion.

[brynpickering]

How link_techs and their attributes are stored in the model xarray Dataset is still a bit of a sticking point. Ideally we would create a link matrix that is indexed over something like (nodes_from, nodes_to, link_techs). However, we then need to index all the link-based parameters over the same dimensions. This means that transmission technologies would not be able to share e.g., the energy_eff parameter with other technologies in the model.

Some ideas:

1. we have an independent link_inputs dataarray with everything indexed over (from, to, link_techs, ...) with some repeated parameter names compared to the main inputs array (e.g., energy_eff, energy_cap_max, ....). This has the disadvantage of being difficult to find for the user and to manage when we mash everything together into parameters in the backend.
2. we prepend all link parameters with link_ and include it in inputs, so you would have link_energy_eff, link_energy_cap_max. The problem is that we then have some magic parameter name changing between user inputs and the array. Something we should try to avoid if we can.
3. we do not allow per-link differences in parameters that are shared with other tech groups. This might be straighforward for e.g. energy_eff, but it clearly doesn't work for e.g., energy_cap_max, which is almost always defined per link.
4. we continue with our current string concatenation approach (same problem as in (2), we do some string magic behind the scenes that is difficult to decipher afterwards) but make it much easier for a user to parse the tech names (currently carrier_prod of a tech called my_tech:my_node is difficult to decipher; does it mean it is transferring energy away from or to my_node?) and supply utility functions to split and merge these transmission techs on-the-fly.
5. .... Ideally there would be a perfect answer here...

[brynpickering]

Explicit links introduced in #518