flexmeasures.data.models.planning
Modules
Classes
- class flexmeasures.data.models.planning.Scheduler(sensor: Sensor | None = None, start: datetime | None = None, end: datetime | None = None, resolution: timedelta | None = None, belief_time: datetime | None = None, asset_or_sensor: Asset | Sensor | None = None, round_to_decimals: int | None = 6, flex_model: dict | None = None, flex_context: dict | None = None, return_multiple: bool = False)
Superclass for all FlexMeasures Schedulers.
A scheduler currently computes the schedule for one flexible asset. TODO: extend to multiple flexible assets.
The scheduler knows the power sensor of the flexible asset. It also knows the basic timing parameter of the schedule (start, end, resolution), including the point in time when knowledge can be assumed to be available (belief_time).
Furthermore, the scheduler needs to have knowledge about the asset’s flexibility model (under what constraints can the schedule be optimized?) and the system’s flexibility context (which other sensors are relevant, e.g. prices). These two flexibility configurations are usually fed in from outside, so the scheduler should check them. The deserialize_flex_config function can be used for that.
- __init__(sensor: Sensor | None = None, start: datetime | None = None, end: datetime | None = None, resolution: timedelta | None = None, belief_time: datetime | None = None, asset_or_sensor: Asset | Sensor | None = None, round_to_decimals: int | None = 6, flex_model: dict | None = None, flex_context: dict | None = None, return_multiple: bool = False)
Initialize a new Scheduler.
- TODO: We might adapt the class design, so that a Scheduler object is initialized with configuration parameters,
- and can then be used multiple times (via compute()) to compute schedules of different kinds, e.g.
If we started later (put in a later start), what would the schedule be? If we could change set points less often (put in a coarser resolution), what would the schedule be? If we knew what was going to happen (put in a later belief_time), what would the schedule have been?
For now, we don’t see the best separation between config and state parameters (esp. within flex models) E.g. start and flex_model[soc_at_start] are intertwined.
- compute() Series | List[Dict[str, Any]] | None
Overwrite with the actual computation of your schedule.
- compute_schedule() pd.Series | None
Overwrite with the actual computation of your schedule.
Deprecated method in v0.14. As an alternative, use Scheduler.compute().
- deserialize_config()
Check all configurations we have, throwing either ValidationErrors or ValueErrors. Other code can decide if/how to handle those.
- deserialize_flex_config()
Check if the flex model and flex context are valid. Should be overwritten.
Ideas: - Apply a schema to check validity (see in-built flex model schemas) - Check for inconsistencies between settings (can also happen in Marshmallow) - fill in missing values from the scheduler’s knowledge (e.g. sensor attributes)
Raises ValidationErrors or ValueErrors.
- deserialize_timing_config()
Check if the timing of the schedule is valid. Raises ValueErrors.
- classmethod get_data_source_info() dict
Create and return the data source info, from which a data source lookup/creation is possible. See for instance get_data_source_for_job().
- persist_flex_model()
If useful, (parts of) the flex model can be persisted here, e.g. as asset attributes, sensor attributes or as sensor data (beliefs).