feat: multi step prediction

[dietervdb-meteo]

This PR introduces inference support for ecmwf/anemoi-core#636 , which creates the possibility for the Forecaster to have multiple output time steps.

In inference the forecast_stepper still loops over autoregressive ('rollout') steps, but in each such step the model now makes multistep_output substeps:

1. multistep_output=1 example:

INFO Lead time: 12:00:00, time stepping: 3:00:00 Forecasting 4 steps through 4 autoregressive steps of 1 predictions each.
INFO Forecasting autoregressive step 0: horizon 3:00:00, freq. 3:00:00 (2022-10-03 03:00:00): 5 seconds.
INFO Forecasting autoregressive step 1: horizon 6:00:00, freq. 3:00:00 (2022-10-03 06:00:00): 0.5 seconds.
INFO Forecasting autoregressive step 2: horizon 9:00:00, freq. 3:00:00 (2022-10-03 09:00:00): 0.5 seconds.
INFO Forecasting autoregressive step 3: horizon 12:00:00, freq. 3:00:00 (2022-10-03 12:00:00): 0.5 seconds.

2. multistep_output=2 example:

INFO Lead time: 12:00:00, time stepping: 3:00:00 Forecasting 4 steps through 2 autoregressive steps of 2 predictions each.
INFO Forecasting autoregressive step 0: horizon 6:00:00, freq. 3:00:00 (2022-10-03 03:00:00, 2022-10-03 06:00:00): 7 seconds.
INFO Forecasting autoregressive step 1: horizon 12:00:00, freq. 3:00:00 (2022-10-03 09:00:00, 2022-10-03 12:00:00): 0.5 seconds.

The current version of the code is a first technically working version, no sanity checks performed yet.
This work is EXPERIMENTAL, considerable work is still required to see if and when this will get merged. In any case that will be after merging of ecmwf/anemoi-core#636

By opening this pull request, I affirm that all authors agree to the Contributor License Agreement.

[dietervdb-meteo]

Multi-out has an issue with accumulated variables that shows up when writing to grib. It seems to go back to a problem with metadata in the checkpoint, so it probably has to be fixed in core. For the moment I have simply suppressed 'tp' output, so that we can continue our scientific evaluation without waiting for this fix in the code. This hardcoded removal of 'tp' in the output makes some tests fail, which is good, so that we wont forget to remove this once the code is closer to merging.

[HCookie]

@dietervdb-meteo Can you provide more context on the grib error, we have had some accumulation / step-range issues in the past?

[dietervdb-meteo]

  File ".../anemoi/inference/grib/encoding.py", line 161, in encode_time_processing
    raise ValueError(
ValueError: Writing tp at step 3 with period 6 for would result in a negative start step -3. Try `write_initial_state: False`
2025-12-05 09:00:35 ERROR 
💣 Writing tp at step 3 with period 6 for would result in a negative start step -3. Try `write_initial_state: False`
2025-12-05 09:00:35 ERROR 💣 Exiting

From what I can see it originates in the period attribute of the (typed_)variable which should originate from the checkpoint variable metadata through typed_variables in metadata.py.
Given the multiple out code has two kind of step sizes: the model step and the rollout step (which is number of outs * model step) it might be I need to update the way some metadata is stored in anemoi core. Or properly interpret the values in anemoi-inference. But I need to understand in more detail what is going on before I can do one or the other.

Unless this all is a red herring and there is something else going on with the accumulations (after I brought the branch up to date with main). I saw the problem appearing after I fixed the 'step' attribute of the state (and brought the branch up to date).

[HCookie]

@dietervdb-meteo We have some work in #392 which may be relevant to this particular issue

[gmertes]

It's not a bug. If the model is writing 3 hourly time steps because of the multi-step output, but the accumulations are 6 hourly, then the accumulation at step 3 will have a base time at step -3.

That PR allows you to skip the variable, so accumulations will only start being written at step 6, but the question is if it even makes sense to output a 6 hourly accumulations at a 3 hourly step. Maybe the accumulations should also be 3 hourly?