search

quintel / etmoses

Online decision support tool to create local energy situations for neighbourhoods, cities and regions with a time resolution of 15 minutes created and maintained by Quintel – Not maintained
https://moses.energytransitionmodel.com
MIT License
11 stars 3 forks source link

Saving base load strategy is not working properly #1453

Closed ChaelKruip closed 7 years ago

ChaelKruip commented 7 years ago

In my LES I have base load (aggregated) but it is not saved when I expect it to be (at moments of congestion): etmoses

antw commented 7 years ago

With a LES containing only the base load (and more units, in order to exceed capacity), the strategy is working:

screen shot 2016-09-22 at 09 25 59

I'll find out why there's no difference in this LES...

antw commented 7 years ago

The reason for this and #1452 is the order in which technologies are calculated. For these two issues, the only thing you need to know is that the order is:

  1. Saving base load (Technologies::OptionalConsumer)
  2. Electric vehicle (Technologies::ElectricVehicle)
  3. Electric heating technologies (Technologies::Buffer)

Here's what happens in the chart:

  1. Saving base load technology runs. This is "capacity constrained", but there is plenty of spare capacity at this point in the calculation. Saving base load receives the energy it wants.
  2. Electric vehicle runs. It is not capacity constrained, and therefore receives the energy it wants (transformer is now over-capacity).

The "saving base load" strategy is not relevant in this LES because the network is not over-capacity when the base load is calculated.

The same thing happens in the chart for #1452:

  1. Electric vehicle runs. It is capacity constrained, and its consumption is therefore reduced so as not to exceed the network capacity.
  2. Heat pump now runs. It isn't capacity constrained, and so its consumption blows up a transformer.

Perhaps the technology order needs to be refined?

(with each of these three categories respecting the order internally).

However that does mean the order in which technologies are computed is no longer set-in-stone, but instead is a "polite suggestion" and depends on which strategies are selected. @ChaelKruip What do you think?

ChaelKruip commented 7 years ago

The "saving base load" strategy is not relevant in this LES because the network is not over-capacity when the base load is calculated.

😲 has this always been the case? I have always thought that the load reducing strategies took the total load (before strategies) into account!

Perhaps the technology order needs to be refined?

Why not put the Capacity-constrained technologies last? Like:

Could the Excess-constrained technologies not solve/create a congestion problem and wouldn't is be wise to have the capacity-constrained technologies to be able to take that into account?

However that does mean the order in which technologies are computed is no longer set-in-stone, but instead is a "polite suggestion" and depends on which strategies are selected.

I think we need to inform the user more explicitly about the order in which strategies are applied and the order in which the technologies with behaviour that can be influenced by those strategies are treated. Eventually, I'd like to give the user the possibility of changing the two orders themselves in the interface.

For now, I have no objection to this although I can't fully gauge the possible effects.

antw commented 7 years ago

😲 has this always been the case? I have always thought that the load reducing strategies took the total load (before strategies) into account!

It has indeed always been this way. Each technology is asked in turn – in the defined order – how much energy they want to consume. They also tell the calculator if they are excess- and/or capacity-constrained. The calculator gives them the appropriate amount of energy. They don't know what the total/final amount of energy consumption will be, because the other technologies haven't had a chance to run yet.

Why not put the Capacity-constrained technologies last?

:+1:

antw commented 7 years ago

For what it's worth, the "mandatory consumption" is unaffected by the calculation order (since mandatory means mandatory).

What this does mean is that a capacity-constrained EV may get less energy for buffering purposes than a non-capacity-constrained EV, even in times when there is no exceedance. For example, a capacity-constrained EV would have a lower priority than a non-capacity-constrained heat pump; this would have the effect of more energy being buffered as heat instead of in the car battery.

I'll implement this and put it on beta for testing.

ChaelKruip commented 7 years ago

What this does mean is that a capacity-constrained EV may get less energy for buffering purposes than a non-capacity-constrained EV, even in times when there is no exceedance. For example, a capacity-constrained EV would have a lower priority than a non-capacity-constrained heat pump; this would have the effect of more energy being buffered as heat instead of in the car battery.

If there is no exceedance, why would the (capacity-constrained) EV buffer less than its maximum? Even if it is lower in the order, if the network allows it, EV will buffer maximally by default right?

antw commented 7 years ago

If there is no exceedance, why would the (capacity-constrained) EV buffer less than its maximum? Even if it is lower in the order, if the network allows it, EV will buffer maximally by default right?

Fair point, and completely accurate. 😆

I think that scenario is true if the EV is capacity- and excess-constrained ("buffer using only local excess") and if P2H is turned on.

ChaelKruip commented 7 years ago

I think that scenario is true if the EV is capacity- and excess-constrained ("buffer using only local excess") and if P2H is turned on.

Because P2H has precedence over EV buffering of excess? That makes sense 😄

antw commented 7 years ago

I think this also necessitates that P2G becomes capacity-constrained, otherwise it's given preference over capacity-constrained technologies, including EVs.

@ChaelKruip Does that sound reasonable?

ChaelKruip commented 7 years ago

I think this also necessitates that P2G becomes capacity-constrained, otherwise it's given preference over capacity-constrained technologies, including EVs.

Remind me, does P2G only use excess from its own node or also excess of other nodes than its own?

If the first, making it capacity-constrained would not change anything really except if multiple technologies are 'fighting' for the same excess. Typically, in real life, excess electricity would be first stored in batteries and EVs (electricity is more valuable than gas or heat as an energy carrier), then converted to either heat (P2H) or gas (P2G). It is actually a question of what investment you have done in these flexibility technologies and how much you need to use them to win back the investment that dictates which technology would get precedence over the other. I think that the order of investment in EUR/MW (expensive first) is roughly:

In the second case, I think it makes a lot of sense to make P2G capacity constrained as it would be bad if the network is congested because excess from one part of the LES is transported to a P2G technology in another part.

Sorry for the wall of text @antw. Hope it helps.

antw commented 7 years ago

Sorry for the wall of text @antw. Hope it helps.

It did, thanks. P2G can take local production from other endpoints, but as the final technology to be calculated this is an act-of-last-resort; i.e. no other technology in the subnet wants the energy, therefore it goes to P2G.

This is already fixed on beta; I'll send it to production shortly (it's easy to rollback if there are any side-effects).