ecPoint updates for IFS cycle 50r1

With each new IFS cycle ECMWF updates, via a recalibration exercise, the decision trees used for its ecPoint post-processing (see Figure 1 below). This is particularly important when there are model physics changes that affect rainfall characteristics. In cycle 50r1 fundamental changes were made to the convection scheme. Practically, these brought benefits for users in raw model output: notably more propagation inland of rainfall associated with (SST-triggered) marine convection, and more propagation downstream of convection triggered by upslopes. So rainfall patterns in forecasts have changed. Not only that, but to achieve these structural improvements a proportion (ordinarily 40%) of the snow and rain particulates in the model column are now commuted across from the convection scheme into the large scale scheme. This implies that the meaning of "convective precipitation" in model output has changed. And in turn the convective precipitation ratio (CPR = (convective precipitation accumulation in a period) / (total precipitation accumulation in that period) ), which has been a key variable used by ecPoint, now has different characteristics. Occurrence, worldwide, of high values of CPR is much lower in 50r1 than it was 49r1, whilst intermediate values are more common.

Figure 1: Schematic of an ecPoint post-processing decision tree. Based on what classes (for a given gridbox, member and time interval), different governing variable values fall into (the branches at each level in the hierarchy) we apply a mapping function (1-D matrix) of multiplication factors to the raw model rainfall forecast, to deliver equiprobable forecast values of rainfall for the said period, as would be measured by a raingauge randomly situated within the said gridbox.

This all necessitated a re-think and a restructuring of the ecPoint decision trees, as shown on the 2 tables below. Alongside these decision tree changes, we have now started archiving the output in ECMWF's MARS archive (under the heading "weather-type-subgrid-calibration"). At the same time the ecPoint outputs have been expanded, to encompass 6h, 12h and 24h periods, when previously only 12h periods had been available. The ecPoint products retain their "EXPERIMENTAL" status.

49r1 Decision tree structure

• Approximately 400 decision tree leaves used.
• Minimum case count allowed, in the calibration data, for a decision tree leaf ~ 200.
• There are generally 2 to 5 classes for each level in the hierarchy. Sometimes, due to case count limitations or lack of dependancy, there are no classes at level 5, even occasionally at level 4.
• Whilst there is some consistency between breakpoints used for class definitions (e.g. 0.25, 0.5, 0.75 for CPR), lower down the tree these breakpoints tend to vary somewhat between branches
• Post-processed ecPoint outputs stored locally at ECMWF, not on MARS. Comprises:
  • 99 quantiles for the full ENS+Control (1,2,...99) *
  • gridbox-scale bias-corrected rainfall values for each member for each period
  • weather-type indicators - 5 digit integer, one digit for each level in the hierarchy - for each member for each period (for full post-processing traceability, signifies the decision tree leaf used)
• Valid forecasts available: Daily for 00Z, 12Z runs *
• Valid periods available:
  • 12-hourly (overlapping): T+0-12, T+6-18, T+12-24, ..., T+234-246. *
• Products available for users in ecCharts and OpenCharts have been based on * above.

50r1 Decision tree structure

• Approximately 1400 decision tree leaves used in each case.
• Minimum case count allowed, in the calibration data, for a decision tree leaf ~ 2000.
• There are typically 4 classes for each level in the hierarchy. Sometimes, due to case count limitations, there are fewer classes at the lower levels, or even no classes at all.
• There is strong consistency between the breakpoints used for class definitions (e.g. 0.2, 0.4, 0.7 for CPR) within each of the 3 cases (6h, 12h, 24h)
• Post-processed ecPoint outputs stored on MARS. Comprises:
  • 99 quantiles for the full ENS+Control (1,2,...99) **
  • gridbox-scale bias-corrected rainfall values for each member for each period
  • weather-type indicators - an n digit integer, one digit for each of the n levels in the said hierarchy - for each member for each period (for full post-processing traceability, signifies the decision tree leaf used)
• Valid forecasts available: Daily for 00Z, 06Z, 12Z and 18Z runs **
• Valid periods available:
  • 6-hourly (non-overlapping): T+0-6, T+6-12, T+12-18, ..., T+138-144 **
  • 12-hourly (overlapping): T+0-12, T+6-18, T+12-24, ..., T+234-246.  (but only up to T+144 for 06Z and 18Z runs) **
  • 24-hourly (overlapping): T+0-24, T+12-36, T+24-48, ..., T+336-360.  (but only up to T+144 for 06Z and 18Z runs) **
• Products available for users in ecCharts and OpenCharts are currently based on ** above.

MARS keywords:

• Point values (Perturbed members + Control combined):  type: "pfc", param: "228", levtype: "sfc", quantile: "n:100" (where n=1,2,..,99), stream: "enfo"          
        

• Bias-corrected gridbox (Perturbed members):           type: "gbf", param: "228", levtype: "sfc", stream: "enfo", number: m (where m=1,2,..,50)                  

• Gridbox weather Type (Perturbed members):             type: "gwt", param: "228", levtype: "sfc", stream: "enfo", number: m (where m=1,2,..,50)
    

• Bias-corrected gridbox (Control):                     type: "gbf", param: "228", levtype: "sfc", stream: "oper" 

• Gridbox weather Type (Control):                       type: "gwt", param: "228", levtype: "sfc", stream: "oper"
   

In each case, the method of specifying the step dictates whether the requirement is for a 6-hourly or a 12-hourly or a 24-hourly product, as shown in the following examples: 

• step: "18-24" (6-hourly, ending T+24);  step: "90-102" (12-hourly, ending T+102);  step "48-72" (24-hourly, ending T+72)
   

Rationale behind new decision tree structures:

Development of the new decision tree structures was based on extensive tests, examining also other variables; only a short overview is given here.

To maintain some backwards compatibility, and also recognising that CPR is still a pivotal governing variable for post-processing, we have kept CPR at the top of the hierarchy for all 3 period lengths (6,12,24h), but at the same time have elevated the importance of the "Max MUCAPE" variable, in each case, to hierarchy level 3, from level 4 used with 49r1. "Max MUCAPE" is now considered to be complimentary to CPR in defining whether the situation is convective, as well as being a metric of how much convective instability there is. It was just the latter of these that was considered relevant for 49r1.

At level 4 we have introduced the new governing variable of dewpoint depression (DPD); this follows on from investigation of poor (over)forecasting of rain reported by a member state user in 2025 (49r1), other case studies of extreme rainfall (as discussed here for the 2024 Valencia floods), and systematic tests with both 49r1 and 50r1 that highlighted a strong dependance of gridscale bias on this quantity: on average high DPDs correlate with substantial over-forecasting, whilst very small DPDs correlate with under-forecasting. Users may also notice noteworthy improvements over more mountainous areas related to inclusion of this variable.

For the 6-hourly period alone we adopt also a local solar time variable (LST), which aims to help the post-processing address systematic errors in the diurnal cycle of convection. This was previously adopted in the MISTRAL project (see here). It makes no sense to use this with 24h periods, and even with 12h periods it becomes unhelpful.

Tests indicate that gridscale biases have negligible dependance on the total amount of precipitation forecast (TP, level 2 in each hierarchy); however there is, unsurprisingly, a strong dependance of sub-grid variability on this quantity, which markedly affects the forecast point values (type = pfc), and it is for this reason that we retain this at level 2, as with 49r1.

Evidently the decision tree structure rationale is very multifaceted, and one can see how it has been very carefully formulated, and expanded, to match up with the features of new cycle 50r1. We thus expect the 50r1 ecPoint products to deliver even more added value for users, versus the raw model output, than have previous versions.

For reference the original ecPoint paper can be found here.