You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Table of Contents

Seasonal forecasts and the Copernicus Climate Change Service (C3S)

Introduction to seasonal forecasting

The production of seasonal forecasts, also known as seasonal climate forecasts, have experienced a huge transformation in the last few decades: from a purely academic and research exercise in the early 90s to the current situation where several meteorological forecast services throughout the world conduct routine operational seasonal forecasting activities. Such activities are devoted to provide estimates of statistics of weather in the seasonal and monthly time scales, and they lie in a place somewhere between conventional weather forecasts and climate predictions.

In that sense, even though seasonal forecasts share some method and tools with weather forecasting they are part of a different paradigm which requires treating them in different ways. Seasonal forecasts instead of trying to answer to the question "how is the weather going to look like on a particular location in an specific day?", they will tell us how likely is that the coming season will be wetter, drier, warmer or colder than the usual conditions for that time of year. This kind of long term predictions are feasible due to the behaviour of some of the earth system components which evolve more slowly than the atmosphere (e.g. the ocean, the cryosphere) and in a predictable fashion, so their influence in the earth system can add a noticeable signal.

We consider here as seasonal forecasts data both the higher-frequency (sub-daily and daily) data outputs from numerical earth system weather or climate models and the derived monthly and seasonal products, up to a few months ahead of their initialization date.

Seasonal forecasting within the C3S

The C3S seasonal forecasting products are based on data from several state-of-the-art seasonal prediction systems. Multi-system combinations, as well as predictions from the individual component systems, are available. The centres currently providing forecasts to C3S are ECMWF, The Met Office and Météo-France; in the coming months data produced by Deutscher Wetterdienst and Centro Euro-Mediterraneo sui Cambiamenti Climatici will be included in the C3S multi-system.

DatesECMWFMétéo-FranceMetOffice (*)
from 20170901
to 20171001
4512

from 20171101
onwards

5512

(*) Due to some peculiarities of GRIB formatting and MetOffice forecasting system design, the value of the MARS keyword SYSTEM is changed on a yearly basis, so it has no direct relation with the model version of their system

Table 1: Values of the MARS keyword SYSTEM for the operational C3S seasonal contributors


Each model simulates the Earth system processes that influence weather patterns in slightly different ways, leading to different kinds of model error. The accumulated model errors become significant in comparison to the signal that is meant to be predicted. Some of those errors are shared by the different models but others are not, so combining the output from a number of models enables a more realistic representation of the uncertainties due to model error. The current scientific knowledge have shown that, in most cases, such combined forecasts are more skilful than forecasts from the best of the individual models.

Currently, there are graphical products available in the C3S web site and public access to the data is provided via the ECMWF WebAPI. From 2018 onwards, C3S seasonal forecast data products will be made available via the C3S Climate Data Store (CDS).

Seasonal forecasts are not weather forecasts: the role of the hindcasts

Due to its long leadtimes, a few months since the start date of the forecast, some systematic errors appear that can completely kill the signals that are expected to be predicted. To avoid that, seasonal forecasting systems work with a reference climate to determine how predicted values differ from what is normal for a given region and time of year. The same forecast system is run for past dates, so that kind of model climate can be estimated, and the forecasts be bias-corrected with respect to that model climate. Those forecast runs for earlier years are known as 'hindcasts' or 're-forecasts' and they are a key concept in seasonal forecasting, in such a way that a forecast itself it's not useful without relating it with the relevant hindcasts.

In the image shown below as an example of the crucial role of the hindcasts in seasonal forecasting, a time evolution of monthly average of temperature in a given region is plotted. All the forecast ensemble members (green lines) seem to point to colder than usual conditions when directly compared to the observed climate (blue line). If the model climate derived from the hindcasts (red line) is taken into account the conclusion is quite different, with all the forecast ensemble members now consistently pointing to warmer than usual conditions.

Additionally to their unavoidable role to correct those systematic errors, hindcasts are also used to assess the skill of the different seasonal forecasting systems. In that way, the real-time forecasts are expected to behave with the same skill that the system has shown for past dates, i.e. the skill shown by the hindcasts.

Note that for reasons related with the availability of computing resources, the hindcasts usually have fewer ensemble members per start date than the real-time forecasts, e.g. ECMWF SEAS5 5 has 51 members for the real-time forecasts, and just 25 members for the hindcasts.

How the seasonal forecasting systems build their ensembles? "Burst" mode versus "lagged" mode

N members at 1st month

N members at specific dates (different production schedules)

Production schedules in seasonal forecasting systems

Table with production per system and per forecast/hindcast type


Description of the c3s-seasonal dataset in the MARS archive

Data tree

MMSF

MSMM

MMSA

*** Note: check EUROSIP documentation (it is said that MMSA is not calculated for "lagged" ensembles)

High frequency data (stream MMSF)

TYPE=fc (hidden)

YEAR (note, hindcasts formally equivalent to forecasts)

MONTH

ORIGIN (ecmf, lfpw, egrr)

SYSTEM (hidden, usually... always [are we going to have at some point different systems for the same start date... e.g. MetOffice]?)

LEVTYPE (sfc, plev)

DATE (it is hidden for ecmf, lfpw and 1st of the current month for egrr)


Leaf contents: number, step (freq= 6h, 24h, 12h), [level], parameter

Monthly means and other monthly statistics (stream MSMM)

Derived probability products

TYPE  (em, ensemble mean; hcmean: hindcast climate mean, one for every real-time forecast)

ORIGIN

SYSTEM (optional)

LEVTYPE (sfc, plev)

Leaf contents: date, time***, fcmonth, [level], parameter

*** Ask Manuel, why time is not "hidden" in the final leaf (as it is for MMSF) 

Derived forecast products

TYPE (fcmean/max/min/stdev: "Forecast mean,...")

YEAR (note, hindcasts formally equivalent to forecasts)

ORIGIN

SYSTEM (optional)

LEVTYPE (sfc, plev)

Leaf contents: date, time***, fcmonth, number, [level], parameter

*** Ask Manuel, why time is not "hidden" in the final leaf (as it is for MMSF) 

Real-time forecasts monthly anomalies (stream MMSA)

Derived probability products

TYPE  (em, ensemble mean)

ORIGIN

SYSTEM (optional)

LEVTYPE (sfc, plev)

Leaf contents: date, time***, fcmonth, [level], parameter

*** Ask Manuel, why time is not "hidden" in the final leaf (as it is for MMSF) 

Derived forecast products

TYPE (fcmean "Forecast mean")

ORIGIN

SYSTEM (optional)

LEVTYPE (sfc, plev)

Leaf contents: date, time***, fcmonth, number, [level], parameter

*** Ask Manuel, why time is not "hidden" in the final leaf (as it is for MMSF) 


  • No labels