You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem seems to manifest when the exclusion bounds are not contained inside the inclusion bounds, the algorithm seems to be very naive and just do:
Which doesn't really work when there is effectively no exclusion bounds for some case.
This was discovered while migrating to the microgrid API v0.17, which uses a set of allowed ranges instead a pair of inclusion/exclusion bounds.
Also when working with allowed sets, the calculation should be much more straightforward, and probably handling edge cases will have more predictable results. For example now if we have something like: incl = [100, 1000]; excl = [100, 200], is 100 an allowed value or not? This is not clear. With ranges, this can be clearly represented as [100, 100], [200, 1000] or just [200, 1000] depending on if 100 is allowed or not.
The text was updated successfully, but these errors were encountered:
The battery pool bounds calculation is buggy and these tests are wrong
(see frequenz-floss#1180).
By switching to using ranges of bounds, the buggy behaviour changes and
make these tests fail.
Fixing them is difficult without switching to using ranges natively
first, so we just skip these tests for now.
Signed-off-by: Leandro Lucarella <[email protected]>
What happened?
In
tests/timeseries/_battery_pool/test_battery_pool.py
,test_all_batteries_power_bounds
, the first test scenario is something like this:Adding some logging, this is the result of the initial state (we have battery 5 with inverter 4 and battery 8 with inverter 7):
So we have the same data for both battery chains, that look like:
So the end result is twice these bounds, as it is one per battery chain:
For the first test scenario, the inverter 7 (for battery 8) gets new bounds:
Note that the exclusion bounds are not contained in the inclusion bounds.
This is the extra info for the tests:
So the initial data is:
And this is how this looks like:
So the resulting bounds for each battery chain should be:
So the total resulting bounds should be:
Nevertheless, the battery pool is producing:
And the tests are validating this wrong result.
Extra information
The problem seems to manifest when the exclusion bounds are not contained inside the inclusion bounds, the algorithm seems to be very naive and just do:
Which doesn't really work when there is effectively no exclusion bounds for some case.
This was discovered while migrating to the microgrid API v0.17, which uses a set of allowed ranges instead a pair of inclusion/exclusion bounds.
Also when working with allowed sets, the calculation should be much more straightforward, and probably handling edge cases will have more predictable results. For example now if we have something like:
incl = [100, 1000]; excl = [100, 200]
, is100
an allowed value or not? This is not clear. With ranges, this can be clearly represented as[100, 100], [200, 1000]
or just[200, 1000]
depending on if 100 is allowed or not.The text was updated successfully, but these errors were encountered: