ECMWF IFS Vtable

[paparao]

Hello,

I am using ECMWF IFS operational forecast data (0.25 degree) from:

https://data.ecmwf.int/forecasts/YYYYMMDD/00z/ifs/0p25/oper/

Files are named like: 20260425000000-0h-oper-fc.grib2, 20260425000000-3h-oper-fc.grib2 etc.

I am using the following wgrib2 command to convert before running ungrib:

for f in 2026*oper-fc.grib2; do
wgrib2 $f -set_grib_type simple -grib_out simple_$f
done

PROBLEM:
After running ungrib and metgrid with Vtable.ECMWF, the resulting met_em files show:

num_metgrid_levels = 14
NUM_METGRID_SOIL_LEVELS = 0
(no ST000007, SM000007 or SKINTEMP fields)


QUESTIONS:
1) Is there an official recommended Vtable for ECMWF IFS open data (post-2024 format)?
2) Is Vtable.ECMWF_IFS (recently added to WPS) the correct one to use for this dataset?


System info:
WPS version: 4.6.0
WRF version: 4..6.0
Data: ECMWF IFS 0p25 oper, 3-hourly, 0h to 96h
Vtable tested: Vtable.ECMWF (standard)

Thank you for any guidance.

Regards

 

[Ming Chen]

Hi,

Where did you get Vtable.ECMWF_IFS? I don't think it is incldued in official release of WPS.

We have tried to make ECMWF IFS work for WRF initialization. However, due to some special issues in this data, we didn't make it. Please see relevant information at: update era5/ifs soil field processing by jimbresch · Pull Request #266 · wrf-model/WPS

Is it possible that you use other ECMWF data like ERA5?

 

[paparao]

@Ming Chen
Thanks for the reply.
I used the ECMWF IFS Vtable and was able to successfully run ungrib.exe and metgrid.exe and generate the met_em files. However, I noticed that:

• NUM_METGRID_SOIL_LEVELS = 0
• num_metgrid_levels = 14

In general, WRF usually expects at least 4 soil levels for proper land surface model performance and better soil-temperature/moisture evolution during forecasts.
Since the IFS input was not providing soil levels correctly through my current workflow, I tried an alternative approach:

1. I used ECMWF IFS atmospheric variables with Vtable.ECMWF
2. Ran ungrib.exe and generated the atmospheric FILE:*
3. Then I downloaded GFS data for the same simulation period
4. Created a modified Vtable.GFS.soil containing only soil variables (removed atmospheric variables)
5. Ran ungrib.exe again for the GFS soil fields and generated separate soil FILE:*
6. Used both atmospheric (IFS) and soil (GFS) intermediate files together in metgrid.exe

After this, the generated met_em files showed:

• NUM_METGRID_SOIL_LEVELS = 4
• num_metgrid_levels = 14

The WRF model ran successfully, and surprisingly the results looked reasonable. I compared 10-day simulations against METAR observations for T2, RH, and wind speed, and the agreement appears quite good.
My main doubt is regarding the scientific validity of this approach:
Can we scientifically use:

• ECMWF IFS atmospheric fields
• together with NOAA GFS soil fields

for WRF initialization?
The reason I am asking is because the soil layer structures are different between GFS and ECMWF.
GFS soil layers:

• 0–10 cm
• 10–40 cm
• 40–100 cm
• 100–200 cm

whereas ECMWF IFS soil layers are:

• 0–7 cm
• 7–28 cm
• 28–100 cm
• 100–289 cm

So the soil depth definitions and layer thicknesses are clearly different.
Despite this mismatch, the model is still running stably and producing reasonable results, which surprised me.
Could you please guide me on:

1. Whether this hybrid combination is scientifically acceptable
2. Whether WRF internally interpolates/adapts these soil layers
3. Possible risks or inconsistencies of mixing IFS atmospheric fields with GFS land/soil fields
4. The best scientific approach moving forward for operational forecasts or research-quality simulations

I would really appreciate your guidance on whether this method is acceptable or if there is a better recommended workflow for using ECMWF IFS with WRF.






ECMWF IFS Vtable :

@@ -0,0 +1,55 @@
GRIB1| Level| From | To | metgrid | metgrid | metgrid |GRIB2|GRIB2|GRIB2|GRIB2|
Param| Type |Level1|Level2| Name | Units | Description |Discp|Catgy|Param|Level|
-----+------+------+------+----------+----------+------------------------------------------+-----------------------+
129 | 100 | * | | GEOPT | m2 s-2 | | 0 | 0 | | 100 |
156 | 100 | * | | HGT | m | Height | 0 | 3 | 5 | 100 |
130 | 100 | * | | TT | K | Temperature | 0 | 0 | 0 | 100 |
131 | 100 | * | | UU | m s-1 | U | 0 | 2 | 2 | 100 |
132 | 100 | * | | VV | m s-1 | V | 0 | 2 | 3 | 100 |
157 | 100 | * | | RH | % | Relative Humidity | 0 | 1 | 1 | 100 |
165 | 1 | 0 | | UU | m s-1 | U At 10 m | 0 | 2 | 2 | 103 |
166 | 1 | 0 | | VV | m s-1 | V At 10 m | 0 | 2 | 3 | 103 |
167 | 1 | 0 | | TT | K | Temperature At 2 m | 0 | 0 | 0 | 103 |
168 | 1 | 0 | | DEWPT | K | | 0 | 0 | 6 | 103 |
| 1 | 0 | | RH | % | Relative Humidity At 2 m | 0 | 0 | | 103 |
172 | 1 | 0 | | LANDSEA | 0/1 Flag | Land/Sea flag | 2 | 0 | 0 | 1 |
129 | 1 | 0 | | SOILGEO | m2 s-2 | | 0 | 0 | | 103 |
156 | 1 | 0 | | SOILHGT | m | Terrain field of source analysis | 0 | 0 | | 106 |
134 | 1 | 0 | | PSFC | Pa | Surface Pressure | 0 | 3 | 0 | 1 |
151 | 1 | 0 | | PMSL | Pa | Sea-level Pressure | 0 | 3 | 0 | 101 |
235 | 1 | 0 | | SKINTEMP | K | Sea-Surface Temperature | 0 | 3 | | 101 |
31 | 1 | 0 | | SEAICE | 0/1 Flag | Sea-Ice-Flag | 0 | 3 | | 101 |
34 | 1 | 0 | | SST | K | Sea-Surface Temperature | 0 | 3 | | 101 |
141 | 1 | 0 | | SNOW_EC | m | | 0 | 3 | | 101 |
| 1 | 0 | | SNOW | kg m-2 |Water Equivalent of Accumulated Snow Depth| 0 | 3 | | 101 |
139 | 112 | 0 | 7 | ST000007 | K | T of 0-7 cm ground layer | 2 | 0 | 2 | 106 |
170 | 112 | 7 | 28 | ST007028 | K | T of 7-28 cm ground layer | 192 | 128 | 170 | 106 |
183 | 112 | 28 | 100 | ST028100 | K | T of 28-100 cm ground layer | 192 | 128 | 183 | 106 |
236 | 112 | 100 | 255 | ST100289 | K | T of 100-289 cm ground layer | 192 | 128 | 236 | 106 |
39 | 112 | 0 | 7 | SM000007 | fraction | Soil moisture of 0-7 cm ground layer | 192 | 128 | 39 | 106 |
40 | 112 | 7 | 28 | SM007028 | fraction | Soil moisture of 7-28 cm ground layer | 192 | 128 | 40 | 106 |
41 | 112 | 28 | 100 | SM028100 | fraction | Soil moisture of 28-100 cm ground layer | 192 | 128 | 41 | 106 |
42 | 112 | 100 | 255 | SM100289 | fraction | Soil moisture of 100-289 cm ground layer | 192 | 128 | 42 | 106 |
0 | 1 | 0 | 7 | ST000007 | K | T of 0-7 cm ground layer | 2 | 3 | 18 | 151 |
1 | 2 | 7 | 28 | ST007028 | K | T of 7-28 cm ground layer | 2 | 3 | 18 | 151 |
2 | 3 | 28 | 100 | ST028100 | K | T of 28-100 cm ground layer | 2 | 3 | 18 | 151 |
3 | 4 | 100 | 289 | ST100289 | K | T of 100-289 cm ground layer | 2 | 3 | 18 | 151 |
0 | 1 | 0 | 7 | SM000007 | fraction | Soil moisture of 0-7 cm ground layer | 2 | 0 | 25 | 151 |
1 | 2 | 7 | 28 | SM007028 | fraction | Soil moisture of 7-28 cm ground layer | 2 | 0 | 25 | 151 |
2 | 3 | 28 | 100 | SM028100 | fraction | Soil moisture of 28-100 cm ground layer | 2 | 0 | 25 | 151 |
3 | 4 | 100 | 289 | SM100289 | fraction | Soil moisture of 100-289 cm ground layer | 2 | 0 | 25 | 151 |
-----+------+------+------+----------+----------+------------------------------------------+-----+-----+-----+-----+
#
# Vtable for the ECMWF IFS output that can be found at:
# https://data.ecmwf.int/forecasts/ccyymmdd/12z/ifs/0p25/oper/
#
# output includes 13 p-levels (mandatory levels only). 0 to 360-h every 6-h
#
# This Vtable will work with IFS output from before November 2024 (soil level code 106)
# and after Nov 2024 (soil level code 151). If more IFS soil levels are added in the future
# they can be decoded by modifying the Vtable soil fields. Column 1 is the start
# level number, column 2 is the end level number. Columns 3 and 4 contain the
# depth of those levels in cm.
#
# This Vtable has not been tested on any other EC output.

 

[Ming Chen]

Hi Paparao.

Thank you for the update and detailed description of your approach. I have a few concerns about the combination of IFS upper-air data and GFS soil data.

(1) After you ungrib IFS data, can you find landsea in your intermediate files?
(2) Did you include landsea from GFS?
(3) When running metgrid.exe, have you modified METGRID.TBL, so that the landsea from GFS can be used for soil interpolation?
(4) can you check met_em files and see whether soil temperature along coastal regions look reasonable?

To answer your other questions:

(1) You can combine GFS soil data with IFS upper-air data to initialize WRF. The difference in soil levels is not an issue. REAL can handle soil data at various levels. This hybrid combination is scientifically acceptable
(2) Your approach to handle IFS and GFS is correct, except that both data should have their own landsea mask.

Please look at the document here about the landsea issue.

 

[paparao]

Dear @Ming Chen,

Thank you so much for your kind and detailed feedback, and for taking the time to review my approach so thoroughly. Your guidance has been extremely helpful in giving me confidence in my hybrid IFS + GFS setup. I have carefully gone through each of your concerns and here is what I found:

(1) LANDSEA in IFS intermediate files:
Yes, after ungribbing the IFS data, LANDSEA is present in the intermediate files. It is decoded via GRIB1 parameter 172 in the Vtable.ECMWF (Land/Sea flag, 0/1).

(2) LANDSEA from GFS:
Yes, LANDSEA is also included from GFS, decoded via GRIB1 parameter 81 in Vtable.GFS (proportional Land/Sea flag, 1=land, 0 or 2=sea). Both datasets carry their own land-sea mask as you recommended. I have also ensured that GFS is listed after IFS in fg_name in namelist.wps, so that the GFS LANDSEA takes priority and is used for soil interpolation masking.

(3) METGRID.TBL modification:
I checked the METGRID.TBL and confirmed that all soil temperature (ST) and soil moisture (SM) fields are configured with:
masked=water
interp_mask=LANDSEA(0)
This ensures that soil interpolation is performed only over land points, using the GFS LANDSEA mask to define water points — which is exactly what your linked WPS advanced document recommends.

(4) Soil temperature along coastal regions in met_em files:
I inspected the met_em files and the results look reasonable:
• ST000010 over land: Min = 256.51 K, Max = 310.49 K, Mean = 290.69 K — physically consistent
• ST000010 over water: Mean = 285.16 K — essentially the fill value (285 K), confirming proper masking
• Only 136 out of 10,457 water points (1.3%) showed non-fill values, which are minor coastal fringe artifacts where the GFS and IFS coastlines differ by 1–2 grid points. These are harmless as WRF's own LANDMASK will handle them at runtime.
• No suspicious values outside the physical range of 200–340 K were found over land.

I also reviewed the WPS advanced presentation you shared, which was very informative in clarifying the landsea masking workflow for hybrid combinations.
Thank you again for your valuable guidance. Please let me know if there is anything further I should verify before proceeding to real.exe and WRF.

Moving Forward — Validation and Physics Questions:

We are currently validating our WRF output against ground-based METAR (Meteorological Aerodrome Report) observations. However, METAR data in our domain is quite limited, sparse, and in some cases shows flat/non-varying readings, which makes robust statistical validation difficult. Could you suggest any alternative ground observation datasets that other modelers commonly use for validating WRF simulations over South Asia or similar regions? For example, WMO SYNOP, IMD surface networks, ERA5 reanalysis as a verification reference, or any other sources you would recommend?

Secondly, despite the preprocessing being correctly configured, we are currently struggling with model performance for three key variables:

• Wind Speed (WSPD): Underestimation or poor correlation in some coastal and inland areas
• Temperature (T2): Overestimation or underestimation in certain coastal zones/insland areas
• Relative Humidity (RH): Systematic overestimation in several regions

Our current physics and dynamics configuration is as follows:
• Microphysics : WSM6 (mp_physics = 6)
• Longwave/Shortwave Radiation : RRTMG (ra_lw/sw_physics = 4)
• PBL : YSU (bl_pbl_physics = 1)
• Surface Layer : MM5 (sf_sfclay_physics = 1)
• Land Surface : Noah LSM (sf_surface_physics = 2)
• Cumulus : Kain-Fritsch (cu_physics = 1)
• Grid nudging (FDDA) is active above the PBL for UV and T
• Resolution : 28 km, single domain, 42 eta levels
• Integration period : 10 days (May 2026)

Given that this is a South Asia domain with significant coastal influence (Arabian Sea, Bay of Bengal) and complex terrain (Western Ghats, Himalayas), could you suggest any improvements to the physics or dynamics configuration that might help improve correlations for WSPD, T2, and RH? Specifically:

1. Would switching the PBL scheme (e.g., MYJ or MYNN) improve wind speed and boundary layer representation compared to YSU, especially over coastal regions?
2. Would the Eta surface layer (sf_sfclay_physics = 2) be more consistent with MYJ if we switch PBL?
3. For the RH overestimation issue, could the choice of microphysics or cumulus scheme be contributing? Would Thompson (mp_physics = 8) or a different cumulus scheme be worth testing?
4. Are there any dynamics settings (diffusion, damping, or nudging coefficients) in our current namelist that you would suggest adjusting for better performance at 28 km resolution over this region?

We would greatly appreciate any guidance or suggestions based on your experience. Please find our current namelist.input attached above for your reference.

Thank you again for your continued support and generous help.

Best regards
Paparao

 

[Ming Chen]

Hi Paparao,
Thanks for the detailed description of your approach, which is correct and I have no further concerns.
As for the model performance, we are aware that WRF has limitations to accurately reproduce observations. For your case, the physics options look fine to me. But I am thinking that a higher resolution may give you better results, especially when you try to compare WRF results with in-situ observations. Fine-tuning is also important, and such tuning takes quite a lot of time, efforts, numerous experiments, and it is both case- and region-dependent.

Dear @Ming Chen,

Thank you so much for your kind and detailed feedback, and for taking the time to review my approach so thoroughly. Your guidance has been extremely helpful in giving me confidence in my hybrid IFS + GFS setup. I have carefully gone through each of your concerns and here is what I found:

(1) LANDSEA in IFS intermediate files:
Yes, after ungribbing the IFS data, LANDSEA is present in the intermediate files. It is decoded via GRIB1 parameter 172 in the Vtable.ECMWF (Land/Sea flag, 0/1).

(2) LANDSEA from GFS:
Yes, LANDSEA is also included from GFS, decoded via GRIB1 parameter 81 in Vtable.GFS (proportional Land/Sea flag, 1=land, 0 or 2=sea). Both datasets carry their own land-sea mask as you recommended. I have also ensured that GFS is listed after IFS in fg_name in namelist.wps, so that the GFS LANDSEA takes priority and is used for soil interpolation masking.

(3) METGRID.TBL modification:
I checked the METGRID.TBL and confirmed that all soil temperature (ST) and soil moisture (SM) fields are configured with:
masked=water
interp_mask=LANDSEA(0)
This ensures that soil interpolation is performed only over land points, using the GFS LANDSEA mask to define water points — which is exactly what your linked WPS advanced document recommends.

(4) Soil temperature along coastal regions in met_em files:
I inspected the met_em files and the results look reasonable:
• ST000010 over land: Min = 256.51 K, Max = 310.49 K, Mean = 290.69 K — physically consistent
• ST000010 over water: Mean = 285.16 K — essentially the fill value (285 K), confirming proper masking
• Only 136 out of 10,457 water points (1.3%) showed non-fill values, which are minor coastal fringe artifacts where the GFS and IFS coastlines differ by 1–2 grid points. These are harmless as WRF's own LANDMASK will handle them at runtime.
• No suspicious values outside the physical range of 200–340 K were found over land.

I also reviewed the WPS advanced presentation you shared, which was very informative in clarifying the landsea masking workflow for hybrid combinations.
Thank you again for your valuable guidance. Please let me know if there is anything further I should verify before proceeding to real.exe and WRF.

Moving Forward — Validation and Physics Questions:

We are currently validating our WRF output against ground-based METAR (Meteorological Aerodrome Report) observations. However, METAR data in our domain is quite limited, sparse, and in some cases shows flat/non-varying readings, which makes robust statistical validation difficult. Could you suggest any alternative ground observation datasets that other modelers commonly use for validating WRF simulations over South Asia or similar regions? For example, WMO SYNOP, IMD surface networks, ERA5 reanalysis as a verification reference, or any other sources you would recommend?

Secondly, despite the preprocessing being correctly configured, we are currently struggling with model performance for three key variables:

• Wind Speed (WSPD): Underestimation or poor correlation in some coastal and inland areas
• Temperature (T2): Overestimation or underestimation in certain coastal zones/insland areas
• Relative Humidity (RH): Systematic overestimation in several regions

Our current physics and dynamics configuration is as follows:
• Microphysics : WSM6 (mp_physics = 6)
• Longwave/Shortwave Radiation : RRTMG (ra_lw/sw_physics = 4)
• PBL : YSU (bl_pbl_physics = 1)
• Surface Layer : MM5 (sf_sfclay_physics = 1)
• Land Surface : Noah LSM (sf_surface_physics = 2)
• Cumulus : Kain-Fritsch (cu_physics = 1)
• Grid nudging (FDDA) is active above the PBL for UV and T
• Resolution : 28 km, single domain, 42 eta levels
• Integration period : 10 days (May 2026)

Given that this is a South Asia domain with significant coastal influence (Arabian Sea, Bay of Bengal) and complex terrain (Western Ghats, Himalayas), could you suggest any improvements to the physics or dynamics configuration that might help improve correlations for WSPD, T2, and RH? Specifically:

1. Would switching the PBL scheme (e.g., MYJ or MYNN) improve wind speed and boundary layer representation compared to YSU, especially over coastal regions?
2. Would the Eta surface layer (sf_sfclay_physics = 2) be more consistent with MYJ if we switch PBL?
3. For the RH overestimation issue, could the choice of microphysics or cumulus scheme be contributing? Would Thompson (mp_physics = 8) or a different cumulus scheme be worth testing?
4. Are there any dynamics settings (diffusion, damping, or nudging coefficients) in our current namelist that you would suggest adjusting for better performance at 28 km resolution over this region?

We would greatly appreciate any guidance or suggestions based on your experience. Please find our current namelist.input attached above for your reference.

Thank you again for your continued support and generous help.

Best regards
Paparao