Init vs Valid Time Conventions

The WeatherBench 2 evaluation code can work with two forecast time conventions: init-time and valid-time. For all official WB2 evaluation, the init-time convention is used. You can switch between the conventions using the by_init parameter in the config.Data.

Init-time convention

Here, the time dimension of the forecast dataset refers to the initialization time of each forecast. To get the time at which each forecast step is valid, one has to add the lead_time (also called prediction_timedelta). This is the format used by ECMWF. To avoid confusion, the WB2 code internally renames the time dimension to init_time and a valid_time dimension is created from init_time + lead_time.

Note that the time ranges given to the evaluation code (in the Selection instance) refer to the initialization time. This means that for a forecast with a lead time of 10 days, time_slice = slice('2020-01-01', '2020-12-31') will include forecasts that run up to 2021-01-10.

Valid-time convention

In the valid-time convention, the time dimension on the forecast dataset refers to the time at which the forecast is valid. Internally, this is renamed to valid_time. To get to the initialization time, one has to subtract the lead time: init_time = valid_time - lead_time.

In this case the time_slice argument is applied to the valid_time, so that time_slice = slice('2020-01-01', '2020-12-31') will only include forecasts that are valid in 2020. However, here some of the forecasts will have been initialized at the end of 2019.

When evaluating a full year of data, the differences in the time convention are minimal.

See compute_init_to_valid_time.py in the command line scripts to convert from init to valid time.

See also this page from the climpred project. There, the init-time convention is referred to as same_init, while the valid-time convention is referred to as same_verif.