Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

(RESOLVED) ERA5 data from CDS or ECMWF

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

A

ahahmann

New member
We have recently started downloading ERA5 reanalysis data to run WRF from CDS (https://cds.climate.copernicus.eu/#!/home) instead of the usual ECMWF mars interface. However, the WPS processing of the new grib files, which appear identical, fails. Here are some details:

1. wgrib or g1print.exe display the proper list of fields, but the order of variables is (slightly) different: 129/130/131/132/157 instead of 129/130/157/131/132
2. ungrib.exe runs without error messages and produces intermediate files
3. The intermediate files apparently contain no data (fields = zero) and metgrid.exe fails.

Has anyone seen the same behaviour? Any suggestions are most welcome.

Thanks!
Andrea and Björn
 
Hi Andrea and Björn,
Can you attach the following:
1) one of the input files you are using
2) namelist.wps
3) the Vtable you are using

and please let me know which version of WPS you are working with. Thanks!
 
I uploaded two grib files:

* ERA5_20070314_0000.grb from CSD - this one fails
* ERA5_20170314_0000.grb from ECMWF - this one is fine.

Thanks
 
Hi,
I have run some tests and am seeing something similar to what you are. I am actually able to run ungrib without a problem and I receive an intermediate file that seems to have the necessary components in it (the difference in behavior could potentially be related to the compilers we are using). However, when running metgrid, it just stalls. As you said, when using the 2017 input, it runs without a problem. I asked our WPS specialist about this and he is going to run some diagnostics to try to determine what is happening. He agrees that everything "appears" okay with the 2007 input file. We will keep you posted. In the meantime, do you mind sending your ungrib.log file so that we can take a look at that? Thanks!
 
This problem is due to the record length of the grib message. In order to accommodate large grids, the EC violates the GRIB1 standards. The fix will require modifications to the bit-level manipulations in gribcode.F. The issue was fixed for NCAR's ds113.1 version of EC data in WPS 4.0 by hardwiring the record length, but this issue appears to be different. The surprising thing is not that the 2007 file doesn't decode, but that the 2017 does.
 
Dear Jim,

ungrib.exe from WPS4.0.1 did not help. We get the same error as with the previous version.

Do you have any suggestions on how to solve this problem? We have long simulations to complete and we ran out of forcing data. Retrieving ERA5 files directly from ECMWF is totally impossible at the moment.

Best regards,
Andrea
 
Hi Andrea,
We have not corrected the particular problem you are seeing in the code yet. Jim is speaking of a similar fix that took place, but indicates that he believes this problem is different, and that there will need to be some sort of modification to the ungrib/src/gribcode.F file. At the moment, we haven't resolved this, and unfortunately due to lack of resources, it could be a bit before we are able to. In the meantime, you are welcome to do a little digging and if you find a modification that works, we would love to see it. Otherwise, we will let you know when the problem has been resolved on our end. I apologize for the inconvenience.
 
Dear all,

I have the same problem. When using the ERA5 data from CDS, metgrid.exe works fine, but in met_em files, the first level of some fields (e.g TT, RH) is all zero, which leads to crash in real.exe

Is there any solution yet?

Cheers,
Xun
 
Hello,

We have found a work around this problem. If one does not specify the target resolution in the CDS download the files produced are OK for ungrib and metgrid. Something is changed in the grib file header that screws up the ungrib process when 0.3 x 0.3 is requested. Perhaps not enough digits? Anyway, this did not solve the problem for us. We could not suddenly start simulations with different resolution of forcing data. But perhaps this could be useful to others, e.g. @Xun_Wang.

Cheers, Andrea
 
Some update:

I think this issue might depend on the grid type of ERA5 data from cds. Before the ERA5 data I downloaded is Gaussian grid because the file size is much smaller, which somehow dose not work with WRF. Today I tried to download the same data but with lonlat grid and it works. However, ERA5 data from ECMWF with gaussian grid also works.
 
You must log in or register to reply here.
Top