Transmission between regions

[sstroemer]

Symmetry constraints

This seems to be "duplicated", why?

c_e_symmetric_transmission_constraint(_region1_2__free_transmission_region1_)_:
+1 energy_cap(_region1_2__free_transmission_region1_)
-1 energy_cap(_region1__free_transmission_region1_2_)
= 0

c_e_symmetric_transmission_constraint(_region1__free_transmission_region1_2_)_:
-1 energy_cap(_region1_2__free_transmission_region1_)
+1 energy_cap(_region1__free_transmission_region1_2_)
= 0

Complicating variables

The variable energy_cap(_region1_2__free_transmission_region1_) (and its symmetrical counterpart) are - as far as I understand - upper limits on energy transmitted, constraining e.g. carrier_con(_region1_2__free_transmission_region1__power___YYYY_DD_MM_HH_mm_). Since they are not subject to costs, they are effectively non-necessary complicating variables that we can not guarantee to be eliminated during presolve (or can we?), creating a total of ~17k constraints.

Splitting

Why are these split anyways? With the current configuration they have to be equal anyways:

c_e_symmetric_transmission_constraint(_region1__free_transmission_region1_3_)_ : -energy_cap(_region1_3__free_transmission_region1_) + energy_cap(_region1__free_transmission_region1_3_)

and I would assume that to be the more common case (with the exception being e.g. non-symmetric NTCs, ...). Could be beneficial to use a single variable here per default? (or am I missing something in the LP)

[brynpickering]

Transmission has always been a thorn in our side.

Symmetry constraints: that's just because it is easier to define two constraints from an internal implementation perspective (we don't have to check whether the reciprocal constraint has been defined first, which would be a bit of a pain). Since it's only indexed over nodes and techs, it would involve a negligible performance hit.

Possibly "complicating" variables: I would expect presolve to handle these tbh. We can't be going around and making sure that every single constraint is / isn't doing something. It's most likely that energy_cap would have a cost associated with it for transmission. Nevertheless, it's quite difficult in a generic framework to do this kind of cleanup ourselves because it might not be simple to get an overview of which constraints/costs are binding or not.

Splitting: this is just so we can use the same variable names to define technologies, irrespective of what group they are in. If we consolidated the transmission link ones, we would need a uniquely defined variable for capacity (link_cap?), flow across links (link_flow?), etc., and corresponding unique parameter definitions, since they would no longer be node-based parameters, but link-based ones (see #324 for more discussion on this topic). I'm not against it, just that internal data structures and UI would need to change accordingly.