Do not heat up the environment

[timtroendle]

Problem description

There is an implicit sector coupling feature in Calliope which makes Calliope heat up transmission links whenever too much energy is available. See the minimal model below.

In my case, wasting electricity on transmission lines seems to be an alternative to curtailing renewables. Wasting electricity on transmission lines has three disadvantages I would say:

1. It's much more difficult to say how much renewable energy has been "curtailed".
2. It's more difficult to say how much energy has been "traded".
3. I assume it makes the problem much harder to solve, because it doubles the amount of independent variables (carrier_prod[transmission]) and it creates plateaus on the feasible set: it really makes no or almost no difference where you burn the electricity.

It astonished me to see how extensive this effect is: quite contrary to my intuition, using the transmission link in both directions in parallel seems to be the normal case, not the exception. This may or may not be related to the fact that I am not using crossover.

It would be great if there was an option to switch off this behaviour.

Steps to reproduce the problem

Minimal model below. The idea here is that demand is often = 10, but the supply must always be 15. Calliope burns the surplus electricity on huge transmission lines.

model:
    name: Transmission test
    timeseries_data_path: '.'

run:
    mode: plan
    solver: cbc
    objective_options.cost_class: {monetary: 1}

techs:
    inflexible_supply:
        essentials:
            name: Inflexible electricity supply
            parent: supply
            carrier: electricity
        constraints:
            lifetime: 25
            energy_cap_equals: 15
            energy_cap_min_use: 1
        costs:
            monetary:
                interest_rate: 0.1
                energy_cap: 20
    demand_elec:
        essentials:
            name: Electricity demand
            carrier: electricity
            parent: demand
        constraints:
            resource: file=demand.csv

    hot_transmission:
        essentials:
            name: 'Power transmission'
            parent: transmission
            carrier: electricity
        constraints:
            energy_cap_max: inf
            energy_eff: 0.95
            lifetime: 25
        costs:
            monetary:
                interest_rate: 0.1
                energy_cap_per_distance: 0.0005

locations:
    0: # Austria
        coordinates: {lat: 47.58707180296529, lon: 14.140267800609571}
        techs:
            demand_elec:
            inflexible_supply:
    1: # Belgium
        coordinates: {lat: 50.64103513383204, lon: 4.661121087007843}
        techs:
            demand_elec:
            inflexible_supply:

links:
    0,1:
        techs:
            hot_transmission:

Calliope version

0.6.4

[timtroendle]

Some data from my case: https://nbviewer.jupyter.org/gist/timtroendle/c291f97b258f8903ce911615e9d8bab0.

[brynpickering]

This issue was essentially solved by introducing the possibility of binary decision variables to control flow to only one direction in a given timestep (135d61f4f0306fa05c88a484d38b1ce54bfbd162). Of course, this will lead to a lot of binary decision variables, since there will be one per timestep, and two per link. The same problem can arise with storage technologies that have losses on charge/discharge.

Sadly, there seems to be no other way to make this change given the current implementation. This issue does point towards improving transmission, such that each link has a single e.g. carrier_flow variable, which can be positive or negative in a timestep, to signify energy flow from one location to another...

[timtroendle]

Thanks for letting me know!

I feared there wasn't an easy LP solution, but I wanted to report this in any case. One could model it with the big M method, although that would likely not be elegant and in particular not solver-efficient.

Even if there was just one variable as you point out, one couldn't model it, no? At least not when there are losses. So maybe, there could be another type of transmission model which does not have losses.

[timtroendle]

See also this comment for some issue related to this behaviour.

[brynpickering]

Even if there was just one variable as you point out, one couldn't model it, no?

Yep, you're right. You would need some way of knowing if it was positive or negative, to know the direction of the flow and thus which end to take the losses at. That would be a MILP problem...

So maybe, there could be another type of transmission model which does not have losses.

This problem should only surface when there are losses. There is no benefit to using both directions of flow in one timestep unless you're trying to dump energy to the environment, which you couldn't do with a lossless line. If it does choose to do it a lot, then it also won't make a difference to the energy balance of the system, so will disappear when considering net flow.

I would be interested to know the computational impact in your model when including the asynchronous prod/con binary variable!

[timtroendle]

This problem should only surface when there are losses. There is no benefit to using both directions of flow in one timestep unless you're trying to dump energy to the environment, which you couldn't do with a lossless line. If it does choose to do it a lot, then it also won't make a difference to the energy balance of the system, so will disappear when considering net flow.

True! Maybe this whole thing is not a Calliope issue, because it's a problem for every LP. It's just that I was surprised to see how extensively it is used in my model.

[brynpickering]

Makes you wonder if it isn't exactly what is already being used by TSOs to ease the impact of over-production from renewables 😉

But you're right, it is doesn't seem to be a Calliope issue, but rather an LP one. I wonder whether other LP models just don't consider transmission losses? Might be a question to ask the openmod community.

[timtroendle]

Apart from making transmission lines lossless, here's another workaround for cases in which renewable electricity is wasted on transmission lines: adding (possibly small or very small) variable costs to either the generation of renewable electricity or the transmission, or both. This must lead to curtailment of renewables rather than wasting electricity on the transmission lines.

Speculatively, this may make the problem easier to solve as it removes a lot of optimal solutions in which the same amount of electricity is generated, but wasted in different ways on the transmission grid.

[timtroendle]

Closing this as not being a Calliope issue.

[timtroendle]

To add on what I said above: I gave small variable costs to renewables and it seems to decrease the effect, but did not remove it entirely:

https://nbviewer.jupyter.org/gist/timtroendle/cd095245bcdfa34bc2ba2d7435c8ff4f

[brynpickering]

Although not a Calliope issue, I'm going to reopen this as a discussion: there should ideally be some way to resolve this in an LP model.

As to the use of variable costs: I agree that it is one way of solving the issue. In fact, you could add it as a different cost class, which makes it easier to filter out at the end. But it's highly volatile. Each line will require a different value to stop heating up the environment whilst also not acting as a barrier to be used for intended transmission.

I think lossy conversion technologies could be used at each end of the line, allowing the transmission techs to be lossless. It would require to have all supply technologies generate a specific carrier, e.g. 'AC'. Then this can be converted to 'HVAC' for transmission (using these new lossy conversion techs and lossless lines) or to 'LVAC' for meeting demand. Then there are lossless conversion technologies which can convert 'HVAC' to 'LVAC' at the other end of the line, but nothing to convert 'LVAC' to 'HVAC' or to 'AC'. You now can't have a loop constantly losing electricity along the transmission lines. It may be over-complicated, but if it works, could provide an LP solution...?

[sjpfenninger]

Closing this as we will document it applied strategies to deal with it in #325.