feat(optimization): split the control horizon from the forecast tail

The optimizer treated the end of `optimization.horizon_hours` as the end of the
world: energy left in the battery there was worth a single configured price per
kWh, so it either dumped the battery into the last hours or hoarded it,
depending on that one number.

The horizon is now two spans. `horizon_hours` still receives every control
command. The new `optimization.tail_horizon_hours` (default 48 h) is a pure
lookahead that never produces a command. In AUTO terminal-value mode a
deterministic dynamic program solves that tail backwards on a 101-point SoC
grid using the production battery and inverter models - SoC bounds, power caps,
conversion losses, configured charge and export rates, direct-marketing
permission and LCOS on delivered DC energy - and the existing AUTO proxy
supplies the continuation value at the tail end. Genetic fitness reads the
resulting curve. `tail_horizon_hours: 0` restores the plain proxy at the control
end, FIXED is unchanged.

The forecast budget is reported, never enforced by refusal: a tail that does not
fit is shortened to what the forecast covers and reported as
`effective_tail_hours`, and a control horizon that does not fit is warned about
at configuration time and rejected by the optimizer at run time, which knows
which series ran out. `prediction.hours` defaults to 72 so the new defaults fit
out of the box; existing shorter configurations keep starting.

Control arrays and warm-start genomes now begin at the run timestamp rather than
midnight, flagged by `controls_start_at_now` so the adapters still read older
solutions. `forecast_interval_seconds` declares the resolution of shortened
native quarter-hour inputs.

Required forecasts are no longer silently replaced by demo providers. A missing
PV, price, load, feed-in or weather forecast used to rewrite the configured
provider and retry, so a run could quietly optimize against invented data.
Missing values now stay missing, and provider values are held only within their
own source interval instead of being extended indefinitely.

Also fixes a config update that could leave EOS half-updated: the merged
candidate is validated before the singleton is reinitialized.

Four provider tests that hard-coded the old 48 h prediction default are rewritten
to derive their expectations from the configured horizon.
This commit is contained in:
Andreas
2026-09-09 07:56:38 +02:00
parent 88150d46e3
commit a2f4ef6f54
37 changed files with 3589 additions and 502 deletions
+2 -2
View File
@@ -151,7 +151,7 @@ def test_update_data(mock_get, provider, sample_clearout_1_html, sample_clearout
mock_get.return_value = mock_response
expected_start = to_datetime("2024-10-26 00:00:00", in_timezone="Europe/Berlin")
expected_end = to_datetime("2024-10-28 00:00:00", in_timezone="Europe/Berlin")
expected_end = to_datetime("2024-10-29 00:00:00", in_timezone="Europe/Berlin")
expected_keep = to_datetime("2024-10-24 00:00:00", in_timezone="Europe/Berlin")
# Call the method
@@ -160,7 +160,7 @@ def test_update_data(mock_get, provider, sample_clearout_1_html, sample_clearout
provider.update_data()
# Check for correct prediction time window
assert provider.config.prediction.hours == 48
assert provider.config.prediction.hours == 72
assert provider.config.prediction.historic_hours == 48
assert compare_datetimes(provider.ems_start_datetime, expected_start).equal
assert compare_datetimes(provider.end_datetime, expected_end).equal