FlexMeasures / flexmeasures-client / 41726578056
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
41726578056

push

github

web-flow 
fix(FRBC): record what a resource manager declares about its storage (#244)

* fix(FRBC): record what a resource manager declares about its storage

A standard FRBC resource manager announces three things after its system
description: the fill levels it wants to be kept between, the usage it
expects to draw, and what its storage leaks on its own. The base handler
raises NotImplementedError for all three, and the CEM dispatches each as
a task nobody awaits, so asyncio reported each one as "Task exception was
never retrieved". Every connection by a resource manager that sends all
three therefore produced three tracebacks and recorded none of what they
declared. This was measured against a real resource manager, not inferred.

FRBCSimple now implements the three handlers, translating each message
with the helpers that were already there and posting the result. The four
sensors they post to are optional constructor arguments, so no existing
caller has to change: without a sensor, that declaration is not recorded,
and the handler says so, rather than posting it somewhere else or
crashing. A fill-level band is two series, so a target profile is
recorded only where both bounds have a sensor.

A target profile is held inside the fill-level range of the latest system
description, which is what clip_fill_level_target_profile is for. The two
do not have to agree: a night setback can aim below the range, and a
profile sent before a description that narrowed the range can fall
outside it. Where they disagree the range wins, since that is what the
resource manager says its storage can do. Clipping alone can leave a
minimum above its maximum where the whole band is outside the range, so
those collapse to their midpoint, keeping minima at or below maxima
everywhere.

The flooring that schedule_start did inline is now align_to_resolution,
because a usage forecast and a leakage behaviour need it too: FlexMeasures
reads a series on whole resolution steps, and no moment ... (continued)

995 of 1040 relevant lines covered (95.67%)

9.57 hits per line

Jobs
ID Job ID Ran Files Coverage
1 macos-latest - py3.13 - 41726578056.1 6
95.67
GitHub Action Run
2 macos-latest - py3.12 - 41726578056.2 6
95.67
GitHub Action Run
3 macos-latest - py3.10 - 41726578056.3 6
95.67
GitHub Action Run
4 ubuntu-latest - py3.14 - 41726578056.4 6
95.67
GitHub Action Run
5 ubuntu-latest - py3.11 - 41726578056.5 6
95.67
GitHub Action Run
6 macos-latest - py3.11 - 41726578056.6 6
95.67
GitHub Action Run
7 macos-latest - py3.14 - 41726578056.7 6
95.67
GitHub Action Run
8 ubuntu-latest - py3.13 - 41726578056.8 6
95.67
GitHub Action Run
9 ubuntu-latest - py3.12 - 41726578056.9 6
95.67
GitHub Action Run
10 ubuntu-latest - py3.10 - 41726578056.10 6
95.67
GitHub Action Run
Source Files on build 41726578056