Skip to content

Derive seasonal lags from sensor resolution#2157

Open
BelhsanHmida wants to merge 5 commits into
mainfrom
feat/forecast-resolution-aware-lags
Open

Derive seasonal lags from sensor resolution#2157
BelhsanHmida wants to merge 5 commits into
mainfrom
feat/forecast-resolution-aware-lags

Conversation

@BelhsanHmida
Copy link
Copy Markdown
Contributor

Description

  • Make the LightGBM forecaster's seasonal lag configurable.
  • Derive daily seasonal lag steps from the target sensor resolution.
  • Improves daily-seasonality handling for sub-hourly sensors such as PT15M sensors.
  • I have added a changelog entry for this PR.

Look & Feel

N/A

How to test

  • uv run pytest flexmeasures/data/tests/test_forecasting_pipeline.py -q
  • pre-commit run --all-files

Further Improvements

  • Add validation or warnings when the available training history is too short for the requested forecast horizon.

Related Items

Sign-off

  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

Context:
- Forecasting daily seasonality was hard-coded to 24 lag steps.
- That only represents one day for hourly sensors.

Change:
- Add a seasonal_lag_steps parameter to CustomLGBM.
- Keep the previous 24-step default for compatibility.

Signed-off-by: Mohamed Belhsan Hmida <mohamedbelhsanhmida@gmail.com>
Context:
- Daily lag steps depend on the target sensor resolution.
- PT15M sensors need 96 steps to represent one day, not 24.

Change:
- Compute one-day lag steps from the target sensor event resolution.
- Pass the derived value into CustomLGBM during training.

Signed-off-by: Mohamed Belhsan Hmida <mohamedbelhsanhmida@gmail.com>
Context:
- Resolution-aware daily lags need enough training samples for the full requested horizon.
- Three days of PT15M data with a 48h horizon used to produce forecasts on main and should not become a hard failure.

Change:
- Fall back to the legacy 24-step lag pattern when the training window cannot support daily lags for the farthest horizon.
- Add regression coverage for under-sampled and sufficiently sampled PT15M histories.

Signed-off-by: Mohamed Belhsan Hmida <mohamedbelhsanhmida@gmail.com>
@BelhsanHmida BelhsanHmida self-assigned this May 9, 2026
@BelhsanHmida BelhsanHmida marked this pull request as ready for review May 15, 2026 11:13
Signed-off-by: Mohamed Belhsan Hmida <149331360+BelhsanHmida@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the LightGBM forecasting model so daily seasonal lag features can scale with the target sensor resolution, improving support for sub-hourly forecasting.

Changes:

  • Adds configurable seasonal lag parameters to CustomLGBM.
  • Derives daily lag steps from target_sensor.event_resolution during training.
  • Adds a unit test for fallback behavior when history is too short for the requested daily lag.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File Description
flexmeasures/data/models/forecasting/custom_models/lgbm_model.py Adds seasonal lag configuration and fallback logic.
flexmeasures/data/models/forecasting/pipelines/train.py Passes derived daily lag steps and training sample count into CustomLGBM.
flexmeasures/data/tests/test_forecasting_pipeline.py Tests fallback vs daily seasonal lag selection.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +129 to +131
seasonal_lag_steps=max(
int(timedelta(days=1) / self.target_sensor.event_resolution), 1
),
Comment on lines +33 to +36
seasonal_lag_steps=24,
fallback_lag_steps=24,
training_sample_count=None,
min_samples_per_horizon=2,
lag = (
24
self.seasonal_lag_steps
- ( # temporarily make the adaptation to the sensor resolution; To do: inlude a list of seasonal lags to include, given as pd.timedelta objects
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Forecast degradation for longer horizons despite homogeneous input data

2 participants