flexmeasures.data.services.forecasting

Logic around scheduling (jobs)

Functions

flexmeasures.data.services.forecasting.create_forecasting_jobs(sensor_id: int, start_of_roll: datetime, end_of_roll: datetime, resolution: timedelta | None = None, horizons: list[timedelta] | None = None, model_search_term='linear-OLS', custom_model_params: dict | None = None, enqueue: bool = True) → list[Job]

Create forecasting jobs by rolling through a time window, for a number of given forecast horizons. Start and end of the forecasting jobs are equal to the time window (start_of_roll, end_of_roll) plus the horizon.

For example (with shorthand notation):

start_of_roll = 3pm end_of_roll = 5pm resolution = 15min horizons = [1h, 6h, 1d]

This creates the following 3 jobs:

  1. forecast each quarter-hour from 4pm to 6pm, i.e. the 1h forecast

  2. forecast each quarter-hour from 9pm to 11pm, i.e. the 6h forecast

  3. forecast each quarter-hour from 3pm to 5pm the next day, i.e. the 1d forecast

If not given, relevant horizons are derived from the resolution of the posted data.

The job needs a model configurator, for which you can supply a model search term. If omitted, the current default model configuration will be used.

It’s possible to customize model parameters, but this feature is (currently) meant to only be used by tests, so that model behaviour can be adapted to test conditions. If used outside of testing, an exception is raised.

if enqueue is True (default), the jobs are put on the redis queue.

Returns the redis-queue forecasting jobs which were created.

flexmeasures.data.services.forecasting.handle_forecasting_exception(job, exc_type, exc_value, traceback)

Decide if we can do something about this failure: * Try a different model * Re-queue at a later time (using rq_scheduler)

flexmeasures.data.services.forecasting.make_fixed_viewpoint_forecasts(sensor_id: int, horizon: timedelta, start: datetime, end: datetime, custom_model_params: dict | None = None) → int

Build forecasting model specs, make fixed-viewpoint forecasts, and save the forecasts made.

Each individual forecast is a belief about a time interval. Fixed-viewpoint forecasts share the same belief time. See the timely-beliefs lib for relevant terminology.

flexmeasures.data.services.forecasting.make_rolling_viewpoint_forecasts(sensor_id: int, horizon: timedelta, start: datetime, end: datetime, custom_model_params: dict | None = None) → int

Build forecasting model specs, make rolling-viewpoint forecasts, and save the forecasts made.

Each individual forecast is a belief about a time interval. Rolling-viewpoint forecasts share the same belief horizon (the duration between belief time and knowledge time). Model specs are also retrained in a rolling fashion, but with its own frequency set in custom_model_params. See the timely-beliefs lib for relevant terminology.

Parameters

param sensor_id:

int To identify which sensor to forecast

param horizon:

timedelta duration between the end of each interval and the time at which the belief about that interval is formed

param start:

datetime start of forecast period, i.e. start time of the first interval to be forecast

param end:

datetime end of forecast period, i.e end time of the last interval to be forecast

param custom_model_params:

dict pass in params which will be passed to the model specs configurator, e.g. outcome_var_transformation, only advisable to be used for testing.

returns:

int the number of forecasts made

flexmeasures.data.services.forecasting.num_forecasts(start: datetime, end: datetime, resolution: timedelta) → int

Compute how many forecasts a job needs to make, given a resolution

Exceptions

exception flexmeasures.data.services.forecasting.MisconfiguredForecastingJobException