Feat/optional training start

[Flix6x]

Description

• Stop relying on start-date to be set by the user
• Stop relying on end-date to be set by the user
• Start testing the ForecasterParametersSchema directly to validate derivation of timing parameters
• Added changelog item in documentation/changelog.rst

Look & Feel

possible to run forecasting cli command without start_date or end_date:

Examples:

• flexmeasures add forecasts --sensor 20 --start-date "2025-01-01T00:00:00+01"
• flexmeasures add forecasts --sensor 20 --end-date "2025-01-15T00:00:00+01"
• flexmeasures add forecasts --sensor 20

How to test

pytest flexmeasures/data/schemas/tests/test_forecasting.py

...

Further Improvements

• Clarify train-period vs max-training-window in cli.data_add.train_predict_pipeline (and for our first example in forecasting.rst we should mention train-period rather than max-training-window).
• Rename def train_predict_pipeline -> def add_forecast

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #31085330 | 📁 Comparing fa098f9 against latest (64e6040)

🔍 Preview build

Show files changed (5 files in total): 📝 5 modified | ➕ 0 added | ➖ 0 deleted

File	Status
changelog.html	📝 modified
genindex.html	📝 modified
_autosummary/flexmeasures.utils.config_defaults.html	📝 modified
api/v3_0.html	📝 modified
features/forecasting.html	📝 modified

[Flix6x]

It's so nice to have these new test cases to lead the discussion! They will provide a lot of clarity, and I imagine they will find there way into the docs, too, at some point.

My remarks right now are mainly ideas to add more clarity on intent and expectations to those test cases.

[Flix6x]

Let's add the (not floored) belief time to the expectations as well.

[Flix6x]

I think that as a user I would have expected 5 days here.

What is the retrain frequency? The retrain frequency governs the number of cycles, right? Let's add an expectation for that parameter, too.

[Flix6x]

And let's already mention 3 main characteristics in each test case comment:

1. Duration of training period (for 1st cycle)
2. Duration of prediction period
3. Number of cycles / (unique) belief times we expect.

[Flix6x]

This governs how much each horizon is apart, right, rather than the number of cycles.

[Flix6x]

Nice. Let's explicitly mention that for this case we expect the predict start to be computed with respect to the start date.

[Flix6x]

Nice. Let's explicitly mention that for this case we expect the train start to be computed with respect to (floored) now.

[Flix6x]

One more suggested case:

# Test when only end date is given with a prediction period: we expect the train start and predict start to both be computed with respect to the end date.

[Flix6x]

Interesting case. What would the user's intended effect be?

[Flix6x]

Let's also prepend a comment stating the user's intent. For instance, in this case, I just need forecasts within my current planning horizon.

Actually, once having formulated that just now, I immediately recognize that it would make a lot of sense to tie the default prediction window to the app's default planning horizon.