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

WPS with grib ERA5 vs NetCDF ERA5, outputs are different

X

xiaominghu

New member
I conducted WPS on derecho with grib ERA5 files and NetCDF ERA5 files and the outputs are different
The surface winds are the same, but they are different at upper layers, e.g., 800mb, 500mb, see the comparison at surface and 500 mb below with NetCDF on left and GRIB outputs on the right. any idea? Thanks a lot!
Xiaoming Hu
1741751819616.png
 
Hi,
Are both the GRIB files, and the netCDF files using the same type of ERA5 data - for e.g., either the model-level data, or the pressure-level data?
If you haven't already, can you plot the raw input data (from ERA5) to see if they differ at that point? If they are identical as input, does the difference occur after metgrid?
 
For Grib files, I used
./link_grib.csh /glade/campaign/collections/rda/data/d633000/e5.oper.an.pl/201802/e5*grb
./ungrib.exe >& ungrib_presslevel.log

ln -sf namelist.ungrib2 namelist.wps
./link_grib.csh /glade/campaign/collections/rda/data/d633000/e5.oper.an.sfc/201802/e5*grb
./ungrib.exe >& ungrib_surface.log

ln -sf namelist.ungrib3pp namelist.wps
./link_grib.csh /glade/campaign/collections/rda/data/d633000/e5.oper.invariant/197901/e5*grb
./ungrib.exe >& ungrib_invaraint.log

For netCDF files, I used:
python ./era5_to_int.py 2018-02-17_00 2018-02-20_00 >& era5_to_int.py.log

Two runs are just different for ungrib/era5_to_int.py, all other steps (./metgrid.exe, real.exe, wrf.exe) are identical

The WRF with NetCDF is just wrong, see below NetCDF result on the left and Grib on the Right, and satellite image below
My WRF with NetCDF-ERA5 is at /glade/derecho/scratch/xiaominghu/Run/SouthernOcean/WRFV4.6.1/wrfERA52d_Rad4_Snudge_75s_ishallowLambert_GV_derecho_MYNNEDMF.2018021700 Thanks

1741988268980.png
1741988335995.png
 
We did fix a bug in the era5_to_int tool at the end of last week; see NCAR/era5_to_int PR #8.

If you're not already doing so, can you try the current 'main' branch of the era5_to_int code? Or, better still, can you try the code from draft PR #13? If you need any pointers on using the code from a branch other than 'main', just let me know and I'll be glad to help.
 
Actually, it looks like you may be using the model-level ERA5 dataset (since no -i / --isobaric option was provided to era5_to_int). In that case, PR #8 probably wouldn't help. Have you run the calc_ecmwf_p.exe utility program to create intermediate files with 3-d GHT, PRESSURE, and RH?
 
after adding "-i" to era5_to_int, the size of resulted ERA5:2018-02-17_00 files are reduced by half, then metgrid.exe failed to produce met_em*.nc files, see my run under /glade/derecho/scratch/xiaominghu/Run/SouthernOcean/WRFV4.6.1/wrfERA52d_Rad4_Snudge_75s_ishallowLambert_GV_derecho_MYNNEDMFncPressL.2018021700
 
It's possible that there are some variables (e.g., GEOPT) in the intermediate files that are causing problems with netCDF file output from metgrid.exe. We've just merged another set of changes -- PR #12 -- to the era5_to_int tool that remove these unnecessary variables from the intermediate files.

I apologize for trouble, but could you try cloning the most recent era5_to_int tool (with changes from the last hour or so) and re-creating your ERA5 intermediate files?
 
Using the new code, and pressure level data (i.e., era5_to_int -i), the results (right below) look right now, comparing with the previous results with model-level data (138 layers) and old code on the left below. Since I have been using pressure-level data (38 layers) for many years, so I will just stay with the pressure level data (i.e., era5_to_int -i). Thanks
1742011230718.png
 
You must log in or register to reply here.
Top