FlexMeasures / flexmeasures-client / 41825255908
95%

DEFAULT BRANCH: main
Ran
Jobs 10
Files 6
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 95.673%. Remained the same
41825255908

push

github

web-flow 
fix(FRBC): ask for a schedule against what a resource manager declared about its storage (#245)

* fix(FRBC): ask for a schedule against what a resource manager declared

A resource manager says where it wants its storage kept, what it expects to draw
from it and what it leaks. All three are now recorded, and none of them reached
the scheduler: the flex model named only a start state and a pair of bounds, so a
schedule came back exactly as it had before the declarations were recorded.

The flex model now names each of those sensors, where one is configured: the
fill-level band as soc-minima and soc-maxima, the expected usage as soc-usage,
and the leakage as storage-efficiency. An entry is left out rather than naming a
sensor that was never configured, which would have the scheduler plan against an
empty series.

Naming the band is not enough on its own, because a minimum FlexMeasures may not
breach is a hard bound by another name. The declared range is where a resource
manager wants its storage, not the only place its storage can be: a buffer
free-floats above the top of its range, and a schedule that ran out of time
leaves it below the bottom. Asked for as hard bounds, those reachable states made
the job infeasible before its first step, and an infeasible job is answered by the
fallback scheduler, which ignores the band altogether. So the band is asked for
with relax-soc-constraints, which prices a breach of it, and the hard soc-min and
soc-max become wide safety rails: zero, and half again above the declared range,
widened further to take in a start state beyond them. The rails exist only to keep
the problem bounded where nothing else does, such as an hour of negative prices
met by a value on the state of charge at the end.

How far the upper rail sits above the range is the deployment's to choose, through
a new safety_rail_factor, since a storage that cannot overshoot its range at all
wants no gap.

relax-soc-constraints needs no server version che... (continued)

995 of 1040 relevant lines covered (95.67%)

9.57 hits per line

Jobs
ID Job ID Ran Files Coverage
1 ubuntu-latest - py3.14 - 41825255908.1 6
95.67
GitHub Action Run
2 ubuntu-latest - py3.12 - 41825255908.2 6
95.67
GitHub Action Run
3 macos-latest - py3.14 - 41825255908.3 6
95.67
GitHub Action Run
4 macos-latest - py3.10 - 41825255908.4 6
95.67
GitHub Action Run
5 macos-latest - py3.12 - 41825255908.5 6
95.67
GitHub Action Run
6 ubuntu-latest - py3.10 - 41825255908.6 6
95.67
GitHub Action Run
7 ubuntu-latest - py3.13 - 41825255908.7 6
95.67
GitHub Action Run
8 macos-latest - py3.13 - 41825255908.8 6
95.67
GitHub Action Run
9 macos-latest - py3.11 - 41825255908.9 6
95.67
GitHub Action Run
10 ubuntu-latest - py3.11 - 41825255908.10 6
95.67
GitHub Action Run
Source Files on build 41825255908