flexmeasures.data.models.forecasting

Modules

flexmeasures.data.models.forecasting.exceptions

flexmeasures.data.models.forecasting.model_spec_factory

flexmeasures.data.models.forecasting.model_specs

flexmeasures.data.models.forecasting.utils

Functions

flexmeasures.data.models.forecasting.lookup_model_specs_configurator(model_search_term: str = 'linear-OLS') Callable[[...], tuple[ModelSpecs, str, str]]

This function maps a model-identifying search term to a model configurator function, which can make model meta data. Why use a string? It might be stored on RQ jobs. It might also leave more freedom, we can then map multiple terms to the same model or vice versa (e.g. when different versions exist).

Model meta data in this context means a tuple of:
  • timetomodel.ModelSpecs. To fill in those specs, a configurator should accept: - old_sensor: Union[Asset, Market, WeatherSensor], - start: datetime, # Start of forecast period - end: datetime, # End of forecast period - horizon: timedelta, # Duration between time of forecasting and time which is forecast - ex_post_horizon: timedelta = None, - custom_model_params: dict = None, # overwrite forecasting params, useful for testing or experimentation

  • a model_identifier (useful in case the model_search_term was generic, e.g. “latest”)

  • a fallback_model_search_term: a string which the forecasting machinery can use to choose

    a different model (using this mapping again) in case of failure.

So to implement a model, write such a function and decide here which search term(s) map(s) to it.