Closed raffyjef closed 3 years ago
The num_metgrid_levels
option is automatically set to the value in the metgrid data, see https://github.com/GIS4WRF/gis4wrf/blob/59f1a898243ad6c1321669b803ee7316c8e94c87/gis4wrf/core/transforms/project_to_wrf_namelist.py#L44-L46
The official WRF docs confirm this approach: "num_metgrid_levels: number of vertical levels in WPS output (type ncdump -h on one of the met_em* files to find out this number)."
Given all that I'm not sure where the problem underlying problem is.
Can you do an ncdump -h
on the met_em*
files as suggested and post the output here?
PS: Please use Markdown code blocks and the preview function before posting.
Here is the `output: (base) C:\Users\serd>ncdump -h met_em.d01.2020-09-03_12_00_00.nc netcdf met_em.d01.2020-09-03_12_00_00 { dimensions: Time = UNLIMITED ; // (1 currently) DateStrLen = 19 ; west_east = 30 ; south_north = 30 ; num_metgrid_levels = 34 ; num_st_layers = 4 ; num_sm_layers = 4 ; south_north_stag = 31 ; west_east_stag = 31 ; z-dimension0012 = 12 ; z-dimension0016 = 16 ; z-dimension0021 = 21 ;
....
From the output, it shows that the num_metgrid_levels in the WPS output is 34. When running the WRF part, it does not set the num_metgrid_level to 34 but stays as 32. I've tried running other dates and it seems this problem starts when running data from July 2019 and beyond. It works though at dates earlier than July 2019. Thank you.
I have an idea what the issue could be, it may have to do with not cleaning up left-over met_em files which can become an issue when the met dataset is changed within a project. Could you check if there are other met_em files in the run_wps
output folder? If so, can you run ncdump -h
on each of them and check whether num_metgrid_levels
is as expected and also if the date/time in the filename matches your configured dataset selection? If you discover old files in there then a temporary work-around is to remove the run_wps
folder and re-run WPS. The real fix would be to fix the cleanup step in gis4wrf.
I did the clean up and it worked. Awesome! Thanks a lot.
On Sun, Sep 6, 2020, 5:38 PM Maik Riechert, notifications@github.com wrote:
I have an idea what the issue could be, it may have to do with not cleaning up left-over met_em files which can become an issue when the met dataset is changed within a project. Could you check if there are other met_em files in the run_wps output folder? If so, can you run ncdump -h on each of them and check whether num_metgrid_levels is as expected and also if the date/time in the filename matches your configured dataset selection? If you discover old files in there then a temporary work-around is to remove the run_wps folder and re-run WPS. The real fix would be to fix the cleanup step in gis4wrf.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GIS4WRF/gis4wrf/issues/183#issuecomment-687739969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMTTGW4CKKQOGXZLIRFJHDSENKB7ANCNFSM4Q3BZELA .
I am trying to run gis4wrf using datasets from September 1, 2020 12:00:00 to September 1, 2020 18:00:00. All the WPS are working. However during the real.exe compilation, it gives an error message:
As for my understanding, it shows that the number of incoming (from WPS input data) vertical levels is not equal to the num_metgrid_levels in the namelist.input. I've tried changing the num_metgrid_levels to 34 however it changes back to 32 when saved.