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

MISMATCH OF NUMBER OF METGRID LEVELS ONLY 12 HOURS?

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.

I

ikhsanmurad

New member
I have problem on mismatch of number of metgrid levels.
It encounters the error for number of metgrid levels.
So, I have changed the WRF namelist input, it still the same.

It happened only 12th June 2019 from 0000 hrs to 1200 hrs.
After 1200hrs I can run the WRF and get the output files.
 

Attachments

  • namelist.wps
    1.1 KB · Views: 86
  • namelist (1).input
    3.2 KB · Views: 77
Hi,
Can you attach the error log that shows the error message? Can you also issue the following 3 commands:
Code: 
ls -ls met_em* >& log.met_files
Code: 
ncdump -h met_em.d01.2019-06-12_00:00:00.nc >& log.june12
Code: 
ncdump -h met_em.d01.2019-06-13_00:00:00.nc >& log.june13
and then please attach the 3 log.* files?
Thanks!
 
Hi.
Kindly refer attachment for your reviews.
 

Attachments

  • rsl.error.txt
    2.2 KB · Views: 67
  • rsl.error1.txt
    1.4 KB · Views: 66
  • june12.log
    25.8 KB · Views: 61
  • june13.log
    25.8 KB · Views: 65
  • met_files.log
    10.4 KB · Views: 60
Thanks for sending those. Okay, so I realized that this happens to be the date that GFS changed their data from 32 to 34 levels. Take a look at this announcement:
https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=94&t=5451

It looks like you can use the pmin option, which specifies a real value for the minimum pressure level (in Pa) to be processed from the GRIB data. You can play around with that number by running metgrid and then checking the value of "num_metgrid_levels" in the met_em* files afterward to see if you can get them all close to 32 levels. An alternative would be to run metgrid and real.exe separately for the time before and after the change.
 
Hi.
I have done as using pmin=1000 in WPS, but the problem still sames.
Only that 12th June 2019 0600-1200, afterwards its running well.
I have also try on 12th June 2018, its running well.
The problem same as per earlier conversation.
BTW, I have using WRF and WPS V4.

Regards,
Ikhsan
 

Attachments

  • namelist.wps
    1.1 KB · Views: 127
  • namelist.input
    3.1 KB · Views: 95
  • rsl.error.txt
    2.2 KB · Views: 64
  • 201906120600.txt
    25.8 KB · Views: 60
  • 201906121200.txt
    25.8 KB · Views: 65
Hi,
Okay, there are a few options to get past this:
1) You very likely would be okay with setting pmin = 5000, instead of 1000. This would still use the levels up to 50 hPa, and unless you need to use the data above that (which most people don't), you should still get reasonable results with this setting. I tested this and it works (while I also tested setting to 1000, and I see the same problem you did).
2) There is a utility in the WPS/util/ directory called "mod_levs.exe" that will allow you to specify the levels to use for a dataset. Since the GFS data beginning at 2019-06-12_12:00:00 has more levels, you would need to do this for the data starting at that time. You can read more about that option here: https://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.1/users_guide_chap3.html#_WPS_Utility_Programs
3) Instead of using analysis data, you could use the forecast data, where if the data are initialized at 00 UTC on the 12th of June, and are forecast out 24 hours (or whatever) from there, then all the times should have the same levels. The problem with this is that you don't have the final analysis in the data, so the accuracy could potentially be worse.
 
You must log in or register to reply here.
Top