quintel / etengine

Calculation engine for the Energy Transition Model
https://energytransitionmodel.com/
MIT License
15 stars 7 forks source link

Add support for forecast storage orders #1313

Closed antw closed 1 year ago

antw commented 1 year ago

This PR adds support for visitors assigning a custom order in which forecasting/optimizing batteries are run. This behaves exactly like the heat network order and the old flexibility order.

The API accepts a list of batteries, ordered by the user, and stores this list in the graph for use in the merit order.

Requires that the following PR is merged first:

See also

mabijkerk commented 1 year ago

Thanks for this @antw, really quick work! I am noticing some strange behaviour though.

I have set the following local nl2019 scenario **User values (YAML)** households_flexibility_p2p_electricity_market_penetration: 10.0 settings_enable_storage_optimisation_households_flexibility_p2p_electricity: 1.0 settings_enable_storage_optimisation_transport_car_flexibility_p2p_electricity: 1.0 transport_car_using_electricity_availability: 100.0 capacity_of_energy_flexibility_mv_batteries_electricity: 0.0 capacity_of_energy_flexibility_hv_opac_electricity: 0.0 capacity_of_energy_flexibility_flow_batteries_electricity: 0.0 transport_bus_using_electricity_availability: 0.0 transport_truck_using_electricity_availability: 0.0 transport_van_using_electricity_availability: 0.0 capacity_of_energy_battery_wind_turbine_inland: 70000.0 transport_car_using_electricity_share: 25.0 transport_car_using_diesel_mix_share: 6.9005413 **Balanced values (YAML)** transport_car_using_compressed_natural_gas_share: 3.68149807e-08 transport_car_using_gasoline_mix_share: 64.55452869752915 transport_car_using_hydrogen_share: 0.0 transport_car_using_lpg_share: 3.5449299656558693 **Forecast storage order** transport_car_flexibility_p2p_electricity households_flexibility_p2p_electricity

This produces the following behaviour for the household batteries: Hourly stored volume of electricity 2185439

I'm having a hard time understanding why the household batteries would only place a charge in December...

When I make sure that the merit order and (roughly) the capacities are switched for households batteries and batteries in electric cars, then I would expect to see similar results. Instead, it shows behaviour that seems more intuitive: Hourly stored volume of electricity 2185439 (1)

antw commented 1 year ago

I'm not entirely sure this is a bug, unintuitive though it might seem.

This scenario has a great deal of EV capacity installed (100%) and relatively little household capacity (10%). The result is that the EV batteries are sufficient to flatten the residual load, and the household batteries hardly need to take any action to flatten it further.

However, when you place the smaller household batteries first, they work hard to flatten the load (lots of charges and discharges) but lack the capacity to do so completely (or even come close to doing so). The result is that EV batteries are still heavily required to flatten the remaining residual load.

If you change it so that their capacities are closer (both are set to 20%), you get this:

Households → Electric cars

1-households_evs

Electric cars → Households

2-evs_households

mabijkerk commented 1 year ago

Thanks for looking into this. After some further testing I agree that you're right. When I add more solar PV plants, the utilisation of the household batteries increases. I just found it counterintuitive that they only charged in December, but apparently the the electric vehicles were so effective in smoothing the residual load curve that no other 'peaks and troughs' were left to smooth. This is precisely the type of insights we can now generate!

In the future it may be interesting to add a residual load curve chart where forecasting storage technologies are plotted according to their merit order. That way we could show how each storage technology contributes to flattening the curve. This is not in scope at the moment though.