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

HGT Issues in WPS-Generated geo_em.nc

peng

Member
Hi everyone,I’m running into an issue with the geo_em.d04.nc file produced by WPS. I updated the terrain (HGT) using ASTER 30 m GeoTIFFs that I converted, and geogrid.exe reported that the HGT was read successfully.
However, in my five-nest WRF-LES setup with resolutions 9 km → 3 km → 1 km → 0.333 km → 0.111 km, the generated geo_em.d04 and geo_em.d05 files show terrain values that don’t match the actual HGT (see the attached figure).
These HGT anomalies are causing excessively large CFL values during the subsequent WRF-LES runs and are affecting model stability.If anyone could offer suggestions or guidance on what might be causing this and how to resolve it, I would be very grateful. Thank you very much for your time and help!
 

Attachments

  • d01.png
    d01.png
    1.4 MB · Views: 7
  • d02.png
    d02.png
    2 MB · Views: 3
  • d03.png
    d03.png
    1.9 MB · Views: 2
  • d04.png
    d04.png
    1.5 MB · Views: 2
  • d05.png
    d05.png
    1 MB · Views: 2
  • d055_tif.png
    d055_tif.png
    1.2 MB · Views: 3
  • geogrid.log
    149.9 KB · Views: 1
  • namelist.wps
    1.1 KB · Views: 2
I tried shifting the simulation domain and rerunning. This time there were no anomaly points in d04, but they still appeared in d05.
 

Attachments

  • d041.png
    d041.png
    1.5 MB · Views: 2
  • d051.png
    d051.png
    1 MB · Views: 2
Additionally, I still encountered this issue when using the default static data provided by the official, gmted2010_30s, whereas this does not occur in the actual terrain.
 

Attachments

  • d04_30s.png
    d04_30s.png
    1.2 MB · Views: 2
  • d05_30s.png
    d05_30s.png
    702.3 KB · Views: 4
Hi, and apologies for the delay in response. Are you still experiencing this issue? I ran geogrid using your namelist and the default static data and I'm seeing something similar - with what appears to be an error in the data; however, when I increase the size of the domains (I added 100 to each domain size), the geo_em* files aren't showing any irregular spots. I can't say, for sure, why this happens when the domain is smaller, but it may not matter because for WRF, domain sizes should not be smaller than 100x100 grid cells. See Why domains should be at least 100x100 grid spaces.
Try running with larger domains and see if you're able to get further.
 
Hi, and apologies for the delay in response. Are you still experiencing this issue? I ran geogrid using your namelist and the default static data and I'm seeing something similar - with what appears to be an error in the data; however, when I increase the size of the domains (I added 100 to each domain size), the geo_em* files aren't showing any irregular spots. I can't say, for sure, why this happens when the domain is smaller, but it may not matter because for WRF, domain sizes should not be smaller than 100x100 grid cells. See Why domains should be at least 100x100 grid spaces.
Try running with larger domains and see if you're able to get further.
Thank you very much for your answer. This issue still troubles me, and I have used local smoothing to mitigate the effects caused by outliers.
I have reviewed your content regarding “at least 100×100 grid points,” which is very helpful to me. I have a question: does setting at least 100×100 also apply to the largest domain? This would make the first domain cover a much larger area than the study region. When the largest domain resolution is 9 km with 100×100 grids, versus 27 km with 100×100 grids, the domain area would expand several times. Or is it only necessary to ensure that there is a sufficiently large area outside the study region for WRF to evolve?
 
Yes, the rule applies to all domains - even domain 01 (the parent domain). It does make the study area much larger, but it is necessary to make sure the model is able to evolve and has time to resolve things within that area.
 
Yes, the rule applies to all domains - even domain 01 (the parent domain). It does make the study area much larger, but it is necessary to make sure the model is able to evolve and has time to resolve things within that area.
Hello, I set all domains to at least 100×100, but I’m still encountering the same issue with d04 and d05 (even when using the official default geog files). How can I resolve this problem completely?
 

Attachments

  • d01.png
    d01.png
    3.2 MB · Views: 2
  • d02.png
    d02.png
    3.5 MB · Views: 2
  • d03.png
    d03.png
    2.4 MB · Views: 2
  • d04.png
    d04.png
    2.1 MB · Views: 4
  • d05.png
    d05.png
    1.6 MB · Views: 4
  • 1.png
    1.png
    1 MB · Views: 4
  • namelist.wps.png
    namelist.wps.png
    38.2 KB · Views: 3
Hi,
Thank you for trying that. After a bit more testing, I think I've figured out the issue. Since you're using the Lambert Conformal map projection, the settings for truelat1 and truelat2 are important and should be on either side of the center latitude (ref_lat). I tried a test, setting

truelat1 = 18.0
truelat2 = 35.0

and that resolved the issue with HGT. Can you let me know if that works for you. Again, I only tested with the default static fields (geog_data_res = 'default', 'default', 'default', 'default', 'default' ).

You may it useful to see this presentation (specifically the slide named Projections: Lambert Conformal Conic - around 7 and 1/2 minutes into the video). The slides before/after may also be of interest to you.
 
Top