flexmeasures.data.models.forecasting.custom_models.base_model

Functions

flexmeasures.data.models.forecasting.custom_models.base_model.default_n_jobs() int

Number of horizon sub-models to fit or predict at the same time.

A long forecast horizon on a high-resolution sensor creates hundreds of sub-models, one per horizon. Nothing is shared between them, so they are worked on concurrently. Each sub-model is expected to run single-threaded, which keeps the total thread count at one per core.

flexmeasures.data.models.forecasting.custom_models.base_model.resolve_n_jobs(n_jobs: int | None) int

Settle how many horizon sub-models to work on at the same time.

None asks for the default, and anything below 1 still leaves one worker to do the job. Subclasses call this when they need the answer before handing it to BaseModel, for instance to decide how many threads to give each sub-model.

Classes

class flexmeasures.data.models.forecasting.custom_models.base_model.BaseModel(max_forecast_horizon: int, probabilistic: bool, auto_regressive: bool, use_past_covariates: bool, use_future_covariates: bool, ensure_positive: bool = False, n_jobs: int | None = None, *args, **kwargs)

Base model for multi-horizon forecasting.

This class serves as a foundation for forecasting models that predict multiple time steps into the future. It supports probabilistic forecasting.

Design principles for forecasting pipeline: - This design follows the fixed viewpoint forecasting paradigm: each forecasting cycle retrains

the model(s) on an extended training window, then generates predictions.

  • A cycle consists of training on a chosen window of historical data (the train period), followed by generating forecasts over the predict period.

  • self.models typically stores one model per forecast horizon, so that each step into the future can be predicted independently. This is why a dependency exists between self.max_forecast_horizon and the number of models.

  • Each model must implement both fit() and predict().

  • self._setup() is called during initialization to prepare these models (subclasses must implement it).

  • Parameters are validated by ForecasterParametersSchema, which is also a good place to learn more about configuration and expected inputs.

Attributes:

max_forecast_horizon (int): Maximum forecast horizon, indicating the number of steps ahead to predict. probabilistic (bool): Whether the model produces probabilistic forecasts.

Note:

Predictions from this model (or its subclasses) will never yield negative values if ensure_positive=True, as any negative predictions are automatically set to zero.

__init__(max_forecast_horizon: int, probabilistic: bool, auto_regressive: bool, use_past_covariates: bool, use_future_covariates: bool, ensure_positive: bool = False, n_jobs: int | None = None, *args, **kwargs) None
_map_over_horizons(work: Callable[[Any], Any]) list

Do something with every horizon sub-model, concurrently where that helps.

Parameters:

work – what to do with one sub-model, called once per horizon with that sub-model, for instance fitting it or asking it for a prediction.

Returns:

what work returned, in horizon order, whether or not threads were used.

The sub-models share no state, so that order is the only thing concurrency could disturb.

abstractmethod _setup() None

Set up the forecasting models.

Subclasses must implement this method to populate self.models. Typically, one model is created per forecast horizon (up to self.max_forecast_horizon). These models must provide fit() and predict() methods compatible with darts TimeSeries.