Forecasts in Backbone allow you to represent future uncertainty in optimization by supplying multiple possible forecast paths (realized, central, optimistic, pessimistic, etc.) for the same time series.
Forecasts in Backbone allow you to represent future uncertainty in optimization by supplying multiple possible forecast paths (realized, central, optimistic, pessimistic, etc.) for the same time series.
...
@@ -139,14 +140,29 @@ Here, reservoir inflow is smoothed over a 168-hour (weekly) window between the e
...
@@ -139,14 +140,29 @@ Here, reservoir inflow is smoothed over a 168-hour (weekly) window between the e
> 👓 See [Time Series Circulation](../Features/Time-Series-Circulation) for a full list of available rules and parameters.
> 👓 See [Time Series Circulation](../Features/Time-Series-Circulation) for a full list of available rules and parameters.
---
---
## 🚧 Practical Modeling Tips
## :crystal_ball: Nonanticipativity
Nonanticipativity prevents the model from “peeking” into different forecast branches at the very start of each solve.
It forces early decisions (unit commitment, storage use, transfers) to be the same across all non-realized branches.
### Why it matters
Without this, the model might exploit branch-specific futures immediately (e.g. charging storage in one forecast, discharging in another), which is unrealistic.
Nonanticipativity keeps the first hours **robust and consistent**, avoiding artefacts.
### How it works
- Applies only when **multiple forecasts** are active.
- Locks early timesteps `t_nonanticipativity` so that:
-**Unit online status** (`v_online`) is equal across branches.
-**Node balances** (sum of generation, transfers, spillage) are equal across branches.
- Realized and central forecasts remain free; other branches must match the central forecast.
### How to use
- Set [mSettings('nonanticipativity')](../Features/Dictionary#forecast-timing-and-update-settings) = X → applies to the first *X hours* of each solve (0 = off).
- If only one forecast is active, the option has no effect.
- Clearly differentiate between realized (`f00`) and central (`f01`) forecasts.
:link: See also [Schedule Simulation](https://gitlab.vtt.fi/backbone/backbone/-/wikis/Features/Schedule-Simulation#2-key-time-parameters)
- Ensure forecast probabilities logically sum (excluding the realized forecast).
- Adjust forecast timing parameters according to model granularity and forecasting practices.