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

Changing terrain to an idealized shape - which static fields need to be changed?


New member
Hello WRF Forums,

I have a question regarding changing a part of the terrain to an idealized shape, namely taking a mountain range and replacing it with a quasi-uniform (length-wise) shape with the same cross-section as the average cross-section. I know I could open up the binary topography files in QGis and edit them there (of course, first saving the original), and then putting them back into the GEOG folder, and modifying the GEOGRID.TBL accordingly.

However, which static files would also need to be modified to make this cosistent? What about landmask (is that an input field or is that derived from landuse), or the landuse?

I guess I am also asking what the implications of modifying the terrain height ONLY would be. Would the landuse be projected onto the new terrain, so there would be a hole where the old terrain had a water surface?

I guess I could also try this out myself but I would prefer if I did not have to make a bunch of newbie mistakes to arrive at the same conclusion. Thank you very much in advance,

Petar Golem
If this is a real-data case, you will have wrfinput file as the initial condition, in which you have the variable "HGT". This is the terrain height variable, and you can always modify this variable to get an idealized shape. However, WRF/WPS have other variables like landsea mask, soil data, landuse type, soil type and SST etc. These variables must be consistent with each other, and the model doesn't check whether they are consistent with topography. This implies that if you place an ideal terrain over water points, the land use type will remain water. I guess you will have to manage to specify values in LSM to these points.

An alternative option is that you put your ideal terrain over an area without water point, and assume all the LSM variables remain unchanged.

Hope this is helpful for you.
That is correct. You will have a hill over, for example, lake or ocean. But the surface of the hill is all water points, ---- this is certainly unrealistic.
Hello again,

I thought I could open up the met_em files in python (using xarray), modify the terrain height field and then save the met_em file in a separate folder, linking it then to the WRF/run folder.

When I run real with the unmodified met_em file, all is fine, but when I run it with the modified files I get the following error in real (when running tail on the rsl. file):

ims,ime,jms,jme -4 145 -4 145
ips,ipe,jps,jpe 1 140 1 140
DYNAMICS OPTION: Eulerian Mass Coordinate
alloc_space_field: domain 1 , 827321076 bytes allocated
-------------- FATAL CALLED ---------------
error opening for input; bad date in namelist or file not in directory
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

Now, the file names are the same, as is the namelist (have not changed it), yet the error persists. One clue I have is that the modified file is slightly larger - possibly a change in data type (python can do that sometimes)? Also, changing the terrain height did not change the surface pressure - perhaps this is the issue, incompatible pressure at the surface with a higher terrain height?
It is something about xarray or python. I opened a file, made a copy (in python) and saved the copy. Tried to run metgrid but it says it cannot open it. And the saved copy of the file is 0.3 MB larger.
Okay, it is xarray. Using netCDF4 package I was able to modify static fields (and any dynamic one as well), and run the simulation. Cheers!
Please clarify that,
(1) if you modify the data using xarray, real.exe failed
(2) if you modify the data using netCDF4 package, it works.
Can you upload your scripts for me to take a look? I am curious why xarray failed. Thanks.
It is the xarray route that failed. I actually did a test (this is how I figure out it is xarray), where I opened the geo_em file using xarray, copied it and saved the copy, so no actual modifications to the data. When attempting to run metgrid with the copy, it did not work, and the file was slightly larger. Xarray does something to the metadata or formatting that makes the resulting file incompatible.

As for the script, here it is, but again, it is just opening the file, copying and saving it. No modifications required to fail metgrid (in case of modifying geo_em file) or real (in case of modifying met_em file).

ds = xr.open_dataset(path_to_geo_em_or_met_em)
ds_copy = ds.copy()

Using the netCDF4 package, the modification worked. Found it on Researchgate discussion boards.