Incorrect storage behavior in Operate mode

[yannick van til]

Problem description

When running a prespecified suboptimal configuration for a given pv and demand timeseries in operate mode, the storage capacity shows unwanted behavior. Whenever, in the next 24 hour time window, the supply (grid + pv + battery) cannot meet the demand, then the storage capacity jumps to an infeasible increased value at exactly time = 0:00. When this happens, the charge value does not (at all) equal the amount of increased storage capacity, sometimes it is even discharging while the storage state of charge increases (Jan 11).
Also, sometimes simultaneous charge and discharging happens at 0:00 as well (see the 2 large positive and negative peaks at Jan 9 and Jan 10).
Context to the energy system itself can be found below.
The goal for me is to be able to calculate the security of supply for a chosen configuration, by using the unmet demand data.

Steps to reproduce the problem

operatestorageproblem.zip
Download the zip file, and run the model for the 5 scenarios specified below. These 5 scenarios are what I tried to do to fix it.
try 1 and 5 provide the problem (see 2 pictures above), try 2 and 3 create critical errors (no results) and try 4 works fine, but uses plan mode instead of operate mode.

1. scenario = ‘try_1’ —> Applying a storage_cap_equals (per location) override for the battery technology, combined with an energy_cap_per_storage_cap_equals override (for the tech), this ran without critical errors, but the results of the storage are as mentioned (see intro).
2. scenario = ‘try_2’ —> Applying an energy_cap_equals (per location) override for the battery technology, combined with applying an energy_cap_per_storage_cap_equals override (for the tech), this resulted in critical errors occur during the solving (problem proven to be infeasible of unbounded), meaning that no results were created.
3. scenario = ‘try_3’ —> Applying an energy_cap_equals (per location) override for the battery technology, combined with a storage_cap_equals (per location) override for the battery technology, This also resulted in critical errors (problem proven to be infeasible of unbounded).
4. scenario = ‘try_4’ —> Running the same scenario (=‘year2007_3’) in plan mode, to see if the problem lies with the storage technology or with the run mode. This try worked fine, the unmet demand was there as expected, and no weird storage jumps occurred.
5. scenario = ‘try_5’ —> Creating a second “grid” technology (on the locations that undergo “unmet demand”) that has a very high cost, to make the scenario feasible, however there are no critical errors, but the same strange behavior of the storage capacity.

commands used:
import calliope
calliope.set_log_verbosity('INFO', include_solver_output=True)
model = calliope.Model('model.yaml',scenario='year2007_3') ##Choose which scenario you want to see (try_1, try_2, try_3, try_4 or try_5)
model.run()

Calliope version

VERSION
0.6.6-post1

energy system context:

Energy system, X1 has 3 houses, X2 has 3 houses, connected by electricity cables.

[Bryn Pickering]

Hi @Yannickvtil, this looks like it was a bug in 0.6.6 that should now be fixed in 0.6.7. Could you check this?

[Lingkang Jin]

I have encountered a similar issue, the storage seems to balance itself all the time, resulting in an infeasible power capacity of the storage.
I have found that one possible solution is forcing the asynchronicity of storage behavior, However, it consumes so much computational resource making it impossible to do for an entire year energy evaluation.
Hoping there's a simpler fix for this.

[Bryn Pickering]

@Lingkangjin that's just a feature of linear models: you sacrifice physical representation for computational efficiency. One other option is to not have 'energy_eff' applied to the storage technology. If it can't "destroy" energy by simultaneous charge/discharge, it is unlikely to do so.

[Lingkang Jin]

@brynpickering thank you for the explanation!
And I have tried to work around in this way:
-let the simulation run with asynchronicity disabled, in order to have computational efficiency as you pointed out
-Although the power capacity of the storage is not physical, its storage capacity is; So I just did the post-process of the production and the consumption of the power capacity of the storage, simply sum of two vectors, taking into account the efficiency and storage loss parameter (consulting the Calliope documentation), and the result should be the "correct" power capacity.

I think it should be a way to tackle this issue, what do you think about it?