<p>I finally solved this problem with the following steps:</p>

<ul>
<li>Download the ECMWF data separately for model level variables (Q,T,U,V and geopotential) and surface variables. In this way, you will get 'pure' GRIB1 and 'pure' GRIB2 files rather than the hybrid type.</li>
<li>Run ungrib twice: for the model levels files, use <a href="https://gist.github.com/Peter9192/271978591ccab67a780ba4b93435f4a6">this</a> Vtable. For the surface file, use the 'old' Vtable.ECMWF_sigma. Between the two ungrib runs, change the ungrib prefix in the namelist.wps (e.g. I used prefix = 'FILE_ML' and prefix = 'FILE_SFC').</li>
<li>Run util/calc_ecmwf_p.exe. This only works if the program can read both files. To achieve this, make sure that in the metgrid part of the namelist.wps, both input names are given (fg_name = 'FILE_ML','FILE_SFC','PRES',). Not sure whether 'PRES' makes a difference here, but since it will be used for metgrid I already put it there and it worked for me. 'PRES' are the files created by calc_ecmwf_p.exe. Note that you'll also need an 'ecmwf_coeffs' file for this step.</li>
<li>Run metgrid, real and wrf as usual.</li>
</ul>

CC BY-SA 3.0
2017-01-20T19:32:19.083Z
Advice from first hand experience: when you run ungrib.exe, don't run it serially.
BarocliniCplusplus
CC BY-SA 3.0
2017-01-20T22:21:07.203Z
@BarocliniCplusplus What do you mean? ungrib is not a parallel program.
milancurcic
CC BY-SA 3.0
2017-01-20T22:31:07.610Z
@Peter9192 Is the Vtable that you provide in the Gist available from WPS Vtables, or you modified it in any way?
milancurcic
CC BY-SA 3.0
2017-01-20T22:58:59.100Z
@milancurcic I mean, when you compile WPS compile it serially (it does give you other options too) and when you run it, don't use mpirun or ibrun.
BarocliniCplusplus
CC BY-SA 3.0
2017-01-21T09:03:44.567Z
@milancurcic I made that Vtable myself, using the GFS grib2 vtable as an example and taking the correct parameter codes from the [ECMWF website](http://apps.ecmwf.int/codes/grib/param-db).
Peter9192
CC BY-SA 4.0
2019-12-30T13:15:33.000Z
@Peter9192 Is it necessary to have geopotential data? I see you added this in the Vtable.
ShaiK
CC BY-SA 4.0
2020-04-24T10:10:31.593Z
@ShaiK Yes, that's necessary to calculate the pressure at model levels if I remember correctly.
Peter9192
CC BY-SA 3.0
2017-01-20T19:27:35.987Z
2017-01-20T19:27:35.987Z
Peter9192
<p>ECMWF model data comes in a hybrid GRIB format, that is, model level output is stored in GRIB2 messages, whereas surface data still uses GRIB1 format. Ungrib is unable to understand this hybrid GRIB format. Previous posts referred to ECMWF's grib-api which should be able to convert GRIB2 to GRIB1, but this doesn't seem to work since the 2013 update when 137 model levels were introduced. So my question is, how to get it working again?</p>

CC BY-SA 4.0
2020-02-04T12:58:59.283Z
I could not find geopotential in model levels. What is the solution?
user18844
<meteorology><models><atmosphere-modelling><wrf>
Running WRF with ECMWF GRIB2 model levels
Peter9192
# Running WRF with ECMWF GRIB2 model levels

(Asked by: username_0 on 2017-01-20)

ECMWF model data comes in a hybrid GRIB format, that is, model level output is stored in GRIB2 messages, whereas surface data still uses GRIB1 format. Ungrib is unable to understand this hybrid GRIB format. Previous posts referred to ECMWF's grib-api which should be able to convert GRIB2 to GRIB1, but this doesn't seem to work since the 2013 update when 137 model levels were introduced. So my question is, how to get it working again?

**Tags:** meteorology, models, atmosphere-modelling, wrf

> **Comments:**
> **username_1**: I could not find geopotential in model levels. What is the solution?  

---

## 1 answers

### Answer by username_0 on 2017-01-20. Score: 5 | Accepted answer

I finally solved this problem with the following steps:

* Download the ECMWF data separately for model level variables (Q,T,U,V and geopotential) and surface variables. In this way, you will get 'pure' GRIB1 and 'pure' GRIB2 files rather than the hybrid type.
* Run ungrib twice: for the model levels files, use [this](https://gist.github.com/username_0/271978591ccab67a780ba4b93435f4a6) Vtable. For the surface file, use the 'old' Vtable.ECMWF\_sigma. Between the two ungrib runs, change the ungrib prefix in the namelist.wps (e.g. I used prefix = 'FILE\_ML' and prefix = 'FILE\_SFC').
* Run util/calc\_ecmwf\_p.exe. This only works if the program can read both files. To achieve this, make sure that in the metgrid part of the namelist.wps, both input names are given (fg\_name = 'FILE\_ML','FILE\_SFC','PRES',). Not sure whether 'PRES' makes a difference here, but since it will be used for metgrid I already put it there and it worked for me. 'PRES' are the files created by calc\_ecmwf\_p.exe. Note that you'll also need an 'ecmwf\_coeffs' file for this step.
* Run metgrid, real and wrf as usual.

> **Comments:**
> **username_2**: Advice from first hand experience: when you run ungrib.exe, don't run it serially.  
> **username_3**: @username_2 What do you mean? ungrib is not a parallel program.  
> **username_3**: @username_0 Is the Vtable that you provide in the Gist available from WPS Vtables, or you modified it in any way?  
> **username_2**: @username_3 I mean, when you compile WPS compile it serially (it does give you other options too) and when you run it, don't use mpirun or ibrun.  
> **username_0**: @username_3 I made that Vtable myself, using the GFS grib2 vtable as an example and taking the correct parameter codes from the [ECMWF website](http://apps.ecmwf.int/codes/grib/param-db).  
> **username_4**: @username_0 Is it necessary to have geopotential data? I see you added this in the Vtable.  
> **username_0**: @username_4 Yes, that's necessary to calculate the pressure at model levels if I remember correctly.  

---

