how to add a new land use category and let WRF recognize it?

[youhuiqi7455]

Dear WRF Experts

Recently I started my research on WRF. I try to add global gravel distribution data to WRF's CLM and add related parameterization schemes. This data is in netcdf format and includes gravel content, latitude, longitude and depth. I know what I need to do in the WPS section, but I don't know what I should do in the WRF.

With my understanding, I have to let WRF can identify my newly joined Landuse, this part of the modification is in registry.em_common? In addition, I must also join my gravel parameterization program, and finally make my gravel data play a role, then where should the parameterization program join?

In the end, there is a problem, I will eventually run the CLM in WRF, I don't know if this will make me a modification of additional documents (I'm not really sure how CLM works in WRF).

I don't know if my understanding is correct or I may not have clearly express my questions. But I am very eager to get some help.

Thanks a lot!

 

[kwerner]

Hi,
Unfortunately this falls out of the scope of our support. We are able to support the out-of-the-box released WRF code, and can attempt to give pointers to solve other issues if resources allow, but we aren't able to invest a lot of time into modifying code for an individual use. What I can suggest is to look at another similar variable that is brought in from the geogrid program and goes into a physics routine and use that as a general template to follow. I would also advise to start small - just seeing if you can get the basic framework to work properly and then slowly add more specific features to your case. It's also possible someone else on the forum will see your inquiry and will know how to advise you.

 

[youhuiqi7455]

Thank you for reply, kwerner
I'm sorry, I may not express my doubt clearly. I don't want you to modify the code for me, I just have the following questions and hope to get some tips.
1) I have converted the nc file into a binary file that can be used in geogrid(via gdal_translate), and created index and geogrid.tbl with reference to ‘clayfrac’, but the result of geogrid.exe is strange.
###index
type=continuous
projection=regular_ll
dx=0.0833
dy=0.0833
known_x=1.0
known_y=1.0
known_lat = -90
known_lon = -180
wordsize=1
missing_value = -999.
tile_x=4320
tile_y=1680
tile_z=8
units="% of volume"
description="grav_content"
###geogrid.tbl
name = grav_content
priority = 1
dest_type = continuous
masked=water
fill_missing=0.
interp_option = default:four_pt+average_4pt+average_16pt+search
rel_path = default:grav/


It seems that the program treats the depth of the data as an object, not the gravel content. I used python to draw this binary file, and the result seems to be no problem. I don't know where the problem is. I have attached the original nc file, as well as the converted binary file and his description file.

2) I want to use the clm mode in wrf. If I can, I would like to know that I might need to modify those files in the phys folder to add my parameterization scheme.

I'll appreciate any help on this.

 

[mgduda]

I've always found it useful when trying to introduce a new static dataset to plot the binary data after conversion to help in determining correct settings for the 'index' file. Have you tried looking at the converted data (in the 00001-04320.00001-01680 file) with, e.g., a bit of Python:

import numpy as np
import matplotlib.pyplot as plt 
a = np.fromfile('00001-04320.00001-01680', dtype='>i2')
b = a.reshape((8,1680,4320))
plt.imshow(b[0,:,:])
plt.show()

? Are the missing values over water what you were expecting? Are the values over land in the expected range? And do the data begin at the south-west corner and progress eastward and northward?

 

[kwerner]

Thank you @mgduda for responding to the first question.

As to your second question, I'm not sure I understand what you're asking. Are you asking if you'll need to modify the clm physics files in order to add a new parameterization scheme? If so, then yes, you will need to, along with a few other files. There are a few FAQ questions that may provide some guidance on files that may need to be modified. See this one, plus some in the "Adding New Features in WRF" section. Unfortunately most of the physics schemes were provided to us by outside collaborators and we don't know the details of each scheme. This is something you'll have to work on to figure out on your own.

 

[youhuiqi7455]

hi @mgduda
Yes, I used python to draw my binary file, and the result looks consistent with the nc file.

According to your suggestion and my understanding, I added iswater=17 and other items to the index, and also tried to modify known_lat&known_lon, but the result still looks messy. Looks like my gravel content is not recognized at all? But it is indeed included in the binary file. I don't know what to do next, hope you or other experts can give some suggestions. thank so much！

 

[youhuiqi7455]

hi, @mgduda
Yes, I used python to draw my binary file, and the result looks consistent with the nc file.

According to your suggestion and my understanding, I added iswater=17 and other items to the index, and also tried to modify known_lat&known_lon, but the result still looks messy. Looks like my gravel content is not recognized at all? But it is indeed included in the binary file. I don't know what to do next, I hope you or other experts can give some suggestions. thank so much

 

[youhuiqi7455]

@kwerner Thank you very much, it is very helpful to me. However, my first question still bothers me, if you can give me some help, I would be very grateful.

 

[youhuiqi7455]

I suspect that there is a problem with the binary file I converted. When I use the software to view the binary file, its content is very strange. As the picture shows, the values 252 and 25 alternate in the x direction in many places. I think they should be zero. I don't know if this is the cause of the problem.

 

[mgduda]

Yes, I used python to draw my binary file, and the result looks consistent with the nc file.

From the plot you've made, it looks like the (1,1) pixel of the dataset is in the north-west corner, rather than in the south-west corner. You can try adding the following to your 'index' file to tell the geogrid program that the rows in your datasets go from north to south:

row_order = top_bottom

If you create the plot interactively with Python, you can move the mouse cursor around to check some of the field values. Do the values over water match the missing value you've specified in your 'index' file?

 

[youhuiqi7455]

hi @mgduda, sorry, I forgot to update my progress. The cause of the problem may be in the original NC file. I changed another set of data (you can find it here http://globalchange.bnu.edu.cn/research/soilw, name is grav1 and grav2), and the result of the gdal conversion is correct. There is only one missing value. I set this missing value in the index and set row_order = top_bottom (as you said, the starting point of the data is at the northwest corner), the geogrid result is correct.
but, unfortunately, I encountered some new problems. My new information is divided into two files, which contain the upper 4 layers and the lower 4 depths respectively. I tried to use cdo to merge them, but the result was not ideal. I also tried to use the cat command to merge the two binary files, and geogrid runs incorrectly. So I can only add them to geogrid.tbl separately, which is obviously not the best choice, and it may cause trouble for me to join the parameterization scheme. If you can provide a feasible way to merge files, that would be great!

 

[mgduda]

Sorry about the delayed reply. I think it should work to use 'cat' to combine layers into a single file. The layer dimension is the slowest-varying dimension, and the values stored in the geogrid binary files have no header bytes or other metadata. When you say that geogrid runs incorrectly after trying to merge files using 'cat', what error are you seeing?

 

[youhuiqi7455]

Sorry about the delayed reply. I think it should work to use 'cat' to combine layers into a single file. The layer dimension is the slowest-varying dimension, and the values stored in the geogrid binary files have no header bytes or other metadata. When you say that geogrid runs incorrectly after trying to merge files using 'cat', what error are you seeing?

hi @mgduda, after I used ‘cat’ to merge the files, I changed the title_z in the index to 8, geogrid ran for a long time, and then it showed "killed"

 

[mgduda]

Sorry for losing track of this thread! Can you try modifying your GEOGRID.TBL entry so that it looks like the following?

name = grav_content
priority = 1
dest_type = continuous
# masked=water
fill_missing=0.
# interp_option = default:four_pt+average_4pt+average_16pt+search
interp_option = default:four_pt
rel_path = default:grav/

Sometimes the interpolation of masked fields can take an inordinate amount of time; the GEOGRID.TBL entry above should cause the geogrid program to not treat the field as a masked field. If the geogrid program completes in a reasonable amount of time, you could verify that all else looks correct in the new "grav_content" field. Ultimately, it sounds like it would be best to treat "grav_content" as a masked field, but it would be good to first verify that the masked interpolation is the issue.

 

[youhuiqi7455]

Thanks for the reply, the problem has now been resolved, and it works well now!