ERA5: RH not used, surface level of SPECHUMD is -1

[friedemann]

Hi!
I would like to drive WRF 4.1.1 with ERA5, following the instructions here: https://dreambooker.site/2018/04/20/Initializing-the-WRF-model-with-ERA5/. While ungrib.exe, metgrid.exe and real.exe all run successfully, I get this message in rsl.error.0000 from real.exe:

Fatal error BAD VARIABLE DIMENSION in ext_ncd_read_field RH2015-02-01_00:00:00

for every timestep of the met_em-files (real.exe finishes with the message that it ran successfully, though!).
The RH fields in the met_em files have 1 level and are described as "Relative Humidity At 2 m" . The values look realistic. However, calc_ecmwf_p.exe complains: "WARNING: Either TT or SPECHUMD not found. No RH will be computed". A colleague suggested that problems with RH might not be important because WRF uses SPECHUMD instead of RH (the user guide says SPECHUMD and RH are not needed if the other is available). I tested this with a workaround for the warning by calc_ecmwf_p.exe, namely concatenating intermediate surface and 3d files before running it (https://github.com/wrf-model/WPS/issues/113). When I do that, the met_em files have RH fields on all model levels (weirdly, the description still says "Relative Humidity At 2 m" - don't know if that's an issue). I can run real.exe without complaining about RH. I then removed RH from these met_em files, and the output from real.exe (wrfinput and wrfbdy files) was identical - so RH was in fact not used. wrfinput and wrfbdy files do differ, however, from the case without concatenating intermediate files. The difference here must be that the met_em files only contain a GHT field when concatenating intermediate files.

While it seems that the issue with RH might not have an effect, I'm not sure the SPECHUMD fields in my met_em files are OK. They cover all num_metgrid_levels with realistic-looking values, except for the surface level where all values are -1. I haven't found out whether real/wrf are able to work with that, neither online nor from log files (when running WRF with ERA-Interim, I get-1e30 in the RH surface level, and real.exe says it'll use the values from the level above, so I'm suspicious about the lack of a similar log message in the case of SPECHUMD). Surface data for relative humidity and specific humidity aren't available in ERA5. Could someone shed light on this? At this point, I'm not sure whether using ERA5 causes errors because of the humidity-related variables.

Cheers,
Friedemann

 

[kwerner]

Hi Friedmann,
Can you share a few files with me so that I can take a look?
1) namelist.input
2) All rsl* files for running real.exe (you can package these together in a single *.TAR file)
3) the met_em* files you're feeding into wrf. If you see the problem immediately, then just 1 or 2 time periods for each domain will suffice. If these files are too large, take a look at the home page of this forum to look for instructions on uploading large files.
Thanks!

 

[friedemann]

Hi kwerner!
I uploaded the files to Nextcloud:
f34t8842_01.tar - case without concatenating intermediate files
f34t8842_02.tar - case with concatenating intermediate files

Thanks,
Friedemann

 

[kwerner]

Thank you for sending those. I think you will want to use the case with the concatenated files since, as you mentioned, there is no GHT field available when you don't concatenate the intermediate files. I tested both versions and am seeing the same things you did - though I only saw the real.exe error when I set debug_level in the namelist. In general, you'll probably want to remove that when running wrf, as it just adds a lot of junk to your rsl files, making them difficult to read and very large. When you run wrf, just verify that everything looks reasonable.

A couple of other suggestions:
1) Your domain sizes are too small. We always recommend using domains that are at LEAST 100x100 (e_we and e_sn variables). You may want to play around with those a bit to make them larger. You can reference this WPS best practice page, which gives good advice for setting up your domain: https://www2.mmm.ucar.edu/wrf/users/namelist_best_prac_wps.html
2) Your time step is potentially too large. We recommend a time_step no larger than 6xDX for d01, so since you have dx = 36 km, you shouldn't have a time step any larger than 216. Having it too large will possibly lead to CFL errors (instability in the model). You can also reference the best practice page for WRF: https://www2.mmm.ucar.edu/wrf/users/namelist_best_prac_wrf.html

 

[friedemann]

Thanks for the feedback and suggestions!

So to be clear, the surface level of SPECHUMD being -1 everywhere is not an issue? The only check for that I have so far is that I looked at QVAPOR after 1 day of simulation, and the surface level looks reasonable compared to levels above.

 

[kwerner]

Hi,
I don't believe it should be a problem. If you take a look at the METGRID.TBL, under SPECHUMD, there is a default setting of:

fill_lev=200100:const(-1)

Level 200100 is the surface level, and we are asking it to fill that level with values of -1. If your output looks reasonable, I think it's okay to continue on.

 

[friedemann]

Thanks!