Flow battery output capacity seems to be capped below specified output capacity

[mabijkerk]

Issue In this scenario, there is 4500 MW of input capacity installed for energy_flexibility_flow_batteries_electricity. Given that the electricity output capacity as specified by the node is 50% lower than the typical input capacity, the output capacity is 2250 MW:

V(energy_flexibility_flow_batteries_electricity,"number_of_units * electricity_output_capacity")

2,250.0

Throughout the year, there are hours where the maximum input capacity is used:

MAX(V(energy_flexibility_flow_batteries_electricity,electricity_input_curve))

4,500.0000000000655

However, when I look at the output curve of the battery, the maximum output capacity is never used:

MAX(V(energy_flexibility_flow_batteries_electricity,electricity_output_curve))

1,102.5000000000355

The strange thing is that the 1102 MW isn't a sporadic event, based on the output curve it seems like a hard cap on the output capacity. Below the charging behaviours is visualised for the first few hours in the year:

Question @antw would you able to look into this issue and find out what is happening here? I thought it might be related to the distribution of electricity between multiple storage technologies with the forecasting algorithm on, but if I remove the installed capacity of the other storage technologies, the maximum output capacity of the flow batteries does not change.

[mabijkerk]

Two questions that I also have for this issue are about the distribution of electricity across multiple storage technologies with the forecasting algorithm enabled. If I remember correctly, the electricity charged and discharged is distributed across all storage technologies proportionately to their installed capacities, is that right?

1. Does this proportionate distribution take input capacity for charging and output capacity for discharging? The difference between input and output capacity for flow batteries is rather large and only looking at input or only at output capacity might distort behaviour.
2. Does this proportionate distribution change when storage technologies are full? In the screenshot of the scenario below, you can see that in the beginning of the year, the batteries in households are fully charged. Does the proportionate distribution take into account that no charge can be supplied to households when calculating the shares?

[antw]

If I remember correctly, the electricity charged and discharged is distributed across all storage technologies proportionately to their installed capacities.

This is not the case. Each battery runs one after the other.

Battery 1 runs with the initial residual load curve. The battery load is then used to produce a new residual curve, which is the basis for battery 2, and so on...

[mabijkerk]

Thanks for this @antw, that's good to know. How is the order of storage technologies determined, alphabetically ascending using node names?

[antw]

Indeed, they're just sorted by key. Would you prefer to change this to be sorted some other way?

[mabijkerk]

At the moment I don't see a better way to sort the order. Perhaps in the future this is something that we would want to allow users to set themselves, or do some testing to determine a logical order, but that would have to be part of an improvement project.

[antw]

@noracato If you still want to investigate this, here are some hints for where to start.

• ETEngine sends data to Merit, and reads data from Merit after the calculation is complete, through MeritFacade.
• Most of the code in the facade belongs to adapters. These tend to represent "types" of technology. We originally started with basic adapters for generic consumers and producers, but this has grown over the years.
• Battery parks are handled by AlwaysOnBatteryParkAdapter which inherts some of its behaviour from ProducerAdapter.
• Most of the code you see in these adapters is to do with setting up the participants in merit with the correct values. However, methods with inject in their name are usually for reading data from Merit and assigning values to the graph after Merit has run.

The AlwaysOnBatteryParkAdapter is probably a good place to start. You can check its producer_attributes.

The battery part is unusual in that most of the calculation for the technology is not actually performed in Merit. Rather, we have a class in ETEngine – AlwaysOnBatteryPark – that calculates the load of the park before Merit runs. For that reason, it's unlikely that Merit itself is broken.

My approach would be to:

1. Add a battery park to a scenario.
2. Put a binding.pry statement in the adapter's producer_attributes method.
3. Inspect whether the attributes assigned make sense.
4. Play around with the AlwaysOnBatteryPark (which is assigned to @park in the adapter). Call its methods and try to see if anything looks incorrect.
   • The output capacity is assigned in the adapter. Perhaps this capacity is incorrect somehow?
   • Alternatively, maybe the park is doing something wrong with the capacity.

Test coverage of MeritFacade is generally quite poor, but fortunately the battery park does have fairly thorough tests. It might be worth having a glance at those to better understand how the park works.

[mabijkerk]

It does not only apply to the forecasting algorithm. When I set the electricity_output_capacity of the flow batteries equal to the input capacity of 380 MW, open a blank scenario and add the following user_values:

capacity_of_energy_flexibility_flow_batteries_electricity: 500.0
wtp_of_energy_flexibility_flow_batteries_electricity: 32.0
wta_of_energy_flexibility_flow_batteries_electricity: 37.0
capacity_of_energy_power_solar_pv_solar_radiation: 15000.0
capacity_of_energy_power_wind_turbine_inland: 15000.0

I get the following results:

EACH(
  V(energy_flexibility_flow_batteries_electricity,"number_of_units * electricity_output_capacity"),
  MAX(V(energy_flexibility_flow_batteries_electricity,electricity_output_curve))
 )

[
  500.00000000000006,
  977.8991985080365,
]

Even while:

EACH(
  V(energy_flexibility_flow_batteries_electricity,"number_of_units * typical_input_capacity"),
  MAX(V(energy_flexibility_flow_batteries_electricity,electricity_input_curve))
 )

[
  500.00000000000006,
  500.00000000000006,
]

For MV batteries with the same settings (in terms of wtp and wta and installed renewables), this behaviour does occur. In conclusion: it is not related to the forecasting algorithm, it does not occur for other batteries, it does not occur for input capacity. It only seems to occur in the output capacity for a select few hours in the year.

[mabijkerk]

• Level in merit order
• Ratio between input and output capacity
• Attributes specific to the flow batteries
• Check other batteries for similar behaviour

[mabijkerk]

I have tested some more, see this scenario, which is II3050 National governance on PRO, but with the capacity of large scale batteries set to 10000 MW.

Installed output capacities of storage technologies:

• Large-scale batteries: 12500 MW
• OPAC: 11000 MW
• Household batteries: 17600 MW

For all these storage technologies, hours occur where the value of the electricity output curve exceeds the installed output capacity. This issue therefore not only applies to flow batteries. The issue only becomes more apparent when the storage volume relative to the capacity increases. You can view the results in Flow batteries testing.xlsx.

At the 16th of January, each storage technology consecutively exceeds its predetermined installed output capacity (hour 377, 378 and 380, see attached Excel). This happens to be during hours when there is not other flexible electricity supply and the only flexible electricity demand is export (see screenshot below).

Realised output capacity:

• Large-scale batteries (hour 377): 13706 MW
• OPAC (hour 380): 19040 MW
• Household batteries (hour 378): 20723 MW

Conclusions

• The issue with output capacity of storage technologies is not limited to flow batteries: all tested storage technologies (large-scale batteries, OPAC and household batteries) show undesirable behaviour
• It therefore likely is not related to the adjustable volume component of the flow batteries
• It seems to occur mainly in hours when there is no other flexible supply than electricity storage discharge and no other flexible demand than export: however, I have not tested this extensively
• The II3050 scenario has price curve for the interconnector, so that may be related
• The forecasting algorithm is disabled in this scenario, so the issue does not only occur for the algorithm, but also for price-based behaviour

@noracato is this a suitable basis from which you can start a more focussed search into the problem?

[mabijkerk]

A component to check might be the roundtrip efficiency: this should not affect the input or output capacity. Let me know if you need to discuss this further.

[noracato]

In quintel/merit@7b3685db63a03fb811936c92637c14f8cab90329 I fixed that the battery was possibly discharging too much when entering the price senstive merit calculation after already joining the "normal" dispatchable one. You can see compared to your chart @mabijkerk that these little bumps are now gone:

Maybe we can check together if that was the full issue, or if there is more. For instance the other pink and green bumps next to them, they are correct right?

[mabijkerk]

This fix for merit addresses the issue where electricity storage technologies had some unexpected spikes in output. Great work!

It however doesn't address the original issue with the flow batteries.

Simple scenario settings for a blank nl2019 scenario:

capacity_of_energy_flexibility_flow_batteries_electricity: 10000.0
settings_enable_storage_optimisation_energy_flexibility_flow_batteries_electricity: 1.0

Querying the installed and realized output capacity:

EACH(
  V(energy_flexibility_flow_batteries_electricity,"electricity_output_capacity*number_of_units"),
  MAX(V(energy_flexibility_flow_batteries_electricity,electricity_output_curve))
)

The installed output capacity is twice the realized output capacity:

[
  5,000.0,
  2,450.0000000000405,
]

After some further simple tests I can draw the following conclusions:

• It occurs only for the output capacity
• It occurs only when the forecasting algorithm is enabled
• It occurs both when the output capacity is larger than the input capacity and vice versa
• It occurs for any electricity storage technology when the criteria above are met

[ChaelKruip]

Thanks for the clear analysis @mabijkerk!

Just to add: the realized output capacity seems to be equal to the installed output capacity times the efficiency squared: 0.7*0.7*5000 = 2450. Hope that helps!

[github-actions[bot]]

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.