Ask about changing surface data in clm5.0

[majun]

Dear scientist,
Thank you for your previous kind help. With your help, I have successfully run a regional case using clm5.0. One more sentence, Thank you sincerely!
Now，I want to run a high-resolution urban area case (this area including urban, crop, vegetation and lake), each grid resolution is 30m x 30m (about 0.0003°)， with dx is 4° (i.e size of total grid in degrees in longitude direction )，dy is 3° . The final purpose of my study is to produce soil moisture, temperature and surface temperature products with 30m resolution. Howevr, I have some questions about this:

(1) what kind of compset should I choose (If I want crop exist) ?

(1) Is clm5.0 suitable for such high resolution or small scale simulation ?

(2) If theoretically possible, what kind of server configuration is required? For example, how much memory and CPU cores are needed？

(3) If the grid resolution is 30m x30m, how to change surface data? Could I use this area's land use and the mearused urban properties datasets with 30m resolution to replace the original coarse resolution dataset ? Or is there any other suggestions ?

(4) I see an optional urban properties dataset is available(Oleson and Feddema (2018)). However, I can't register through the following website: IAM | THESIS Tools | Urban Properties ,it seems this research program was closed as of August 2018. How can I obtain this source code and gen_data_clm.ncl?

Thanks a lot !

 

[oleson]

(1) For a list of standalone CLM compsets, in ...cime/scripts:

./query_config --compsets clm

Your choice will depend on model (Clm45, Clm50), time period (1850, 2000, historical), whether you want satellite phenology model (SP) or biogeochemistry (Bgc, BgcCrop), and atmospheric forcing (GSWP3 - the default, CRU, Qian).

(2) Not really. I don't know of anyone running CLM at such a high spatial resolution. One main problem is that the input datasets that are used to create a surface dataset that CLM uses are at much lower spatial resolution than 30m. Plus the atmospheric forcing datasets are at much lower spatial resolution. So, unless you derive your own surface datasets and atmospheric forcing that is a better match to your surface spatial resolution, you aren't going to get any spatial variability in your results.

(3) I have no idea, but you are certainly going to need copious amounts of memory and processing power.

(4) See (2)

(5) I can bundle this up and provide it but the urban extent is defined at 1km spatial resolution and the urban properties are only defined for 33 regions across the globe, so there won't be any spatial variability in properties across your domain.

 

[majun]

(1) For a list of standalone CLM compsets, in ...cime/scripts:

./query_config --compsets clm

Your choice will depend on model (Clm45, Clm50), time period (1850, 2000, historical), whether you want satellite phenology model (SP) or biogeochemistry (Bgc, BgcCrop), and atmospheric forcing (GSWP3 - the default, CRU, Qian).

(2) Not really. I don't know of anyone running CLM at such a high spatial resolution. One main problem is that the input datasets that are used to create a surface dataset that CLM uses are at much lower spatial resolution than 30m. Plus the atmospheric forcing datasets are at much lower spatial resolution. So, unless you derive your own surface datasets and atmospheric forcing that is a better match to your surface spatial resolution, you aren't going to get any spatial variability in your results.

(3) I have no idea, but you are certainly going to need copious amounts of memory and processing power.

(4) See (2)

(5) I can bundle this up and provide it but the urban extent is defined at 1km spatial resolution and the urban properties are only defined for 33 regions across the globe, so there won't be any spatial variability in properties across your domain.

thank you so much , I‘m preparing to change the resolution to 1km. If the resolution is 1km, do I need to change the surface dataset ? I'm a little stupid on it.
In addition, I want to ask how can I acquire your optional urban properties dataset(Oleson and Feddema (2018))?

 

[oleson]

I think the best you could do is 0.05deg X 0.05deg spatial resolution given the spatial resolutions of the input datasets, if you don't have the data to modify the surface datasets. Even then, certain input datasets are only available at 0.5deg X 0.5deg resolution and so certain fields will appear "blocky" in your domain.
The optional urban properties datasets are available in the inputdata repository.
You would specify the following dataset for "mksrf_furban" in your surface dataset namelist when creating the surface dataset:

inputdata/lnd/clm2/rawdata/mksrf_urban_0.05x0.05_simyr2000.c170724.nc

You would use the following dataset for maximum building temperature in your land namelist for "stream_fldfilename_urbantv" when setting up and running your simulation:

inputdata/lnd/clm2/urbandata/CLM50_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c160923.nc

 

[majun]

I think the best you could do is 0.05deg X 0.05deg spatial resolution given the spatial resolutions of the input datasets, if you don't have the data to modify the surface datasets. Even then, certain input datasets are only available at 0.5deg X 0.5deg resolution and so certain fields will appear "blocky" in your domain.
The optional urban properties datasets are available in the inputdata repository.
You would specify the following dataset for "mksrf_furban" in your surface dataset namelist when creating the surface dataset:

inputdata/lnd/clm2/rawdata/mksrf_urban_0.05x0.05_simyr2000.c170724.nc

You would use the following dataset for maximum building temperature in your land namelist for "stream_fldfilename_urbantv" when setting up and running your simulation:

inputdata/lnd/clm2/urbandata/CLM50_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c160923.nc

thanks, I will have a try

 

[majun]

I think the best you could do is 0.05deg X 0.05deg spatial resolution given the spatial resolutions of the input datasets, if you don't have the data to modify the surface datasets. Even then, certain input datasets are only available at 0.5deg X 0.5deg resolution and so certain fields will appear "blocky" in your domain.
The optional urban properties datasets are available in the inputdata repository.
You would specify the following dataset for "mksrf_furban" in your surface dataset namelist when creating the surface dataset:

inputdata/lnd/clm2/rawdata/mksrf_urban_0.05x0.05_simyr2000.c170724.nc

You would use the following dataset for maximum building temperature in your land namelist for "stream_fldfilename_urbantv" when setting up and running your simulation:

inputdata/lnd/clm2/urbandata/CLM50_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c160923.nc

Hi,Prof.Oleson,
Sorry to bother you again, I'm still confused about how to select an appropriate compset. My study region is a city cycle(this area including urban, crop, vegetation and lake) , I see I2000Clm50SpGs is usually used in city simulation in the user manual, however it doesn't include crop module. I2000Clm50BgcCropGs includes crop, however it doesn't include SP. It seems like SP and BgcCrop is incompatible. I want to ask what kind of compset should I choose to ensure the simulation accuracy of soil moisture and surface temperature? Thank you so much.

 

[oleson]

That's right, the crop module can't be used in SP mode. However, in SP mode, there is a generic crop type. Seems like if you want to simulate soil moisture and surface temperature for present day, your best bet would be I2000ClmSpGs, since that uses satellite observed data for vegetation (e.g., LAI).

 

[majun]

That's right, the crop module can't be used in SP mode. However, in SP mode, there is a generic crop type. Seems like if you want to simulate soil moisture and surface temperature for present day, your best bet would be I2000ClmSpGs, since that uses satellite observed data for vegetation (e.g., LAI).

thanks

 

[majun]

That's right, the crop module can't be used in SP mode. However, in SP mode, there is a generic crop type. Seems like if you want to simulate soil moisture and surface temperature for present day, your best bet would be I2000ClmSpGs, since that uses satellite observed data for vegetation (e.g., LAI).

Dear oleson,
Now I can run an I2000ClmSpGs case using GSWP3v1 as forcing in clm5.0, I want to run an similar case using clm4.5 model and make a comparison I checked the compsets( ./query_config --compsets clm ) in clm5.0 directory and found there are two similar compsets,i.e.I2000Clm45Sp IHistClm50SpG. I changed the compset and did the same operation as I2000ClmSpGs in clm5.0 directory(using the same surface datasets created by clm5.0) However, when it came to the step"./preview namelists", it showed errors:
(1)I2000Clm45Sp, ERROR: Need to provide valid mapping file between glc and lnd in xml variable glc2lnd_smapname
(2)IHistClm50SpG err=ERROR : CLM build-namelist::CLMBuildNamelist::add_default() : No default value found for flanduse_timeseries.
Are defaults provided for this resolution and land mask?
Which compset should I choose and how should I do to run a similar case using clm4.5 model? (I don't know the meaning of GS and HIST)
Thanks for your help !

 

[oleson]

I don't see an I2000ClmSpGs compset, so I assume you mean I2000Clm50SpGs.
There isn't a corresponding compset for CLM45 with that short name. However, you can use the long name to specify a similar compset.
The long name for I2000Clm50SpGs is:

2000_DATM%GSWP3v1_CLM50%SP_SICE_SOCN_MOSART_SGLC_SWAV

The Gs in the short name (or SGLC in the long name) stands for "glacier stub".

The same case for CLM4.5 would then be:

2000_DATM%GSWP3v1_CLM45%SP_SICE_SOCN_MOSART_SGLC_SWAV

You can use this long name in your create_case command (--compset 2000_DATM%GSWP3v1_CLM50%SP_SICE_SOCN_MOSART_SGLC_SWAV)

The "HIST" is a historical transient compset generally setup to run 1850-2014.

 

[majun]

I don't see an I2000ClmSpGs compset, so I assume you mean I2000Clm50SpGs.
There isn't a corresponding compset for CLM45 with that short name. However, you can use the long name to specify a similar compset.
The long name for I2000Clm50SpGs is:

2000_DATM%GSWP3v1_CLM50%SP_SICE_SOCN_MOSART_SGLC_SWAV

The Gs in the short name (or SGLC in the long name) stands for "glacier stub".

The same case for CLM4.5 would then be:

2000_DATM%GSWP3v1_CLM45%SP_SICE_SOCN_MOSART_SGLC_SWAV

You can use this long name in your create_case command (--compset 2000_DATM%GSWP3v1_CLM50%SP_SICE_SOCN_MOSART_SGLC_SWAV)

The "HIST" is a historical transient compset generally setup to run 1850-2014.

Thanks a lot. I have one more question about the resolution of urban datatsets used in clm5.0. I see the urban spatial area is described by Jackson et al. (2010) at 1km resolution and aggregated to 0.05° in clm. I want to ask that is "urban radiative, thermal,and morphological fields" origional resolution also 1km? If I want to use this 1km urban datatsets(including spatial area and radiative, thermal,and morphological datasets) as clm5.0 surface data, do I need to do additional operation or just download it then replace the 0.05° urban datasets?

 

[oleson]

The urban radiative, thermal, and morphological fields are dimensioned by "regions" and "density_class" There are 33 regions across the globe and 3 density classes. For example, doing an ncdump -h on the urban dataset I pointed you to earlier in this thread:

dimensions:
lat = 3600 ;
lon = 7200 ;
numsolar = 2 ;
numrad = 2 ;
nlevurb = 10 ;
region = 33 ;
density_class = 3 ;
variables:
byte LANDMASK(lat, lon) ;
LANDMASK:units = "unitless" ;
LANDMASK:long_name = "land mask" ;
double LAT(lat) ;
LAT:units = "degrees north" ;
LAT:long_name = "lat" ;
double LON(lon) ;
LON:units = "degrees east" ;
LON:long_name = "lon" ;
double LATIXY(lat, lon) ;
LATIXY:units = "degrees north" ;
LATIXY:long_name = "latitude-2d" ;
double LONGXY(lat, lon) ;
LONGXY:units = "degrees east" ;
LONGXY:long_name = "longitude-2d" ;
double PCT_URBAN(density_class, lat, lon) ;
PCT_URBAN:units = "%" ;
PCT_URBAN:long_name = "percent urban" ;
byte REGION_ID(lat, lon) ;
REGION_ID:units = "unitless" ;
REGION_ID:long_name = "Region ID" ;
float CANYON_HWR(region, density_class) ;
CANYON_HWR:units = "unitless" ;
CANYON_HWR:long_name = "canyon height to width ratio" ;
CANYON_HWR:_FillValue = -999.f ;

Note that PCT_URBAN is dimensioned by density_class (3) and lat and lon, while CANYON_HWR is dimensioned by region (33) and density_class. The CANYON_HWR for a given lat/lon can be identified by using the REGION_ID variable.

Note that on the surface dataset itself, the CANYON_HWR, for example, is dimensioned by density class and lat and lon.
The mksurfdata_map tool does the mapping from fields dimensioned by region and density class on the "raw" urban dataset at 0.05 resolution (e.g., CANYON_HWR) to density class and lat/lon on the surface dataset at the desired spatial resolution automatically. The "spatial resolution" of the CANYON_HWR field will be 1km but will have the same value within a given region.

 

[majun]

The urban radiative, thermal, and morphological fields are dimensioned by "regions" and "density_class" There are 33 regions across the globe and 3 density classes. For example, doing an ncdump -h on the urban dataset I pointed you to earlier in this thread:

dimensions:
lat = 3600 ;
lon = 7200 ;
numsolar = 2 ;
numrad = 2 ;
nlevurb = 10 ;
region = 33 ;
density_class = 3 ;
variables:
byte LANDMASK(lat, lon) ;
LANDMASK:units = "unitless" ;
LANDMASK:long_name = "land mask" ;
double LAT(lat) ;
LAT:units = "degrees north" ;
LAT:long_name = "lat" ;
double LON(lon) ;
LON:units = "degrees east" ;
LON:long_name = "lon" ;
double LATIXY(lat, lon) ;
LATIXY:units = "degrees north" ;
LATIXY:long_name = "latitude-2d" ;
double LONGXY(lat, lon) ;
LONGXY:units = "degrees east" ;
LONGXY:long_name = "longitude-2d" ;
double PCT_URBAN(density_class, lat, lon) ;
PCT_URBAN:units = "%" ;
PCT_URBAN:long_name = "percent urban" ;
byte REGION_ID(lat, lon) ;
REGION_ID:units = "unitless" ;
REGION_ID:long_name = "Region ID" ;
float CANYON_HWR(region, density_class) ;
CANYON_HWR:units = "unitless" ;
CANYON_HWR:long_name = "canyon height to width ratio" ;
CANYON_HWR:_FillValue = -999.f ;

Note that PCT_URBAN is dimensioned by density_class (3) and lat and lon, while CANYON_HWR is dimensioned by region (33) and density_class. The CANYON_HWR for a given lat/lon can be identified by using the REGION_ID variable.

Note that on the surface dataset itself, the CANYON_HWR, for example, is dimensioned by density class and lat and lon.
The mksurfdata_map tool does the mapping from fields dimensioned by region and density class on the "raw" urban dataset at 0.05 resolution (e.g., CANYON_HWR) to density class and lat/lon on the surface dataset at the desired spatial resolution automatically. The "spatial resolution" of the CANYON_HWR field will be 1km but will have the same value within a given region.

Thanks so much, oleson. Is it mean the spatial resolution of the oragional urban datasets of Jackson2010 is also at 1km?

 

[oleson]

I should correct my last sentence to say: The "spatial resolution" of the CANYON_HWR field will be at the same spatial resolution as the surface dataset, but will have the same value within a given region.
The original urban datasets of Jackson2010 are at the same spatial resolutions as OlesonAndFeddema2019. Urban extent is at 1km which is then aggregated to 0.05deg for use by the mksurfdata_map tool to create the surface dataset at the desired spatial resolution. The radiative, thermal, and morphological properties are available by region (33) and density class (3).

 

[majun]

I should correct my last sentence to say: The "spatial resolution" of the CANYON_HWR field will be at the same spatial resolution as the surface dataset, but will have the same value within a given region.
The original urban datasets of Jackson2010 are at the same spatial resolutions as OlesonAndFeddema2019. Urban extent is at 1km which is then aggregated to 0.05deg for use by the mksurfdata_map tool to create the surface dataset at the desired spatial resolution. The radiative, thermal, and morphological properties are available by region (33) and density class (3).

thank you. I opened the model output netcdf file, and see there are three different surface temperature, i.e. skin temperature, ground temperature and vegetation temperature, is this skin temperature a mixture of ground temperature and vegetation temperature? Is it reasonable to compare this skin temperature with modis lst?

 

[oleson]

The variable in the code that is used to output TSKIN is "t_skin_patch", in TemperatureType.F90:

this%t_skin_patch(begp:endp) = spval
call hist_addfld1d(fname='TSKIN', units='K', &
avgflag='A', long_name='skin temperature', &
ptr_patch=this%t_skin_patch, c2l_scale_type='urbans')

You can look at t_skin_patch in the code to see how it is calculated.

I recommend reviewing the literature for the best way to compare modeled temperatures to modis lst.

 

[majun]

The variable in the code that is used to output TSKIN is "t_skin_patch", in TemperatureType.F90:

this%t_skin_patch(begp:endp) = spval
call hist_addfld1d(fname='TSKIN', units='K', &
avgflag='A', long_name='skin temperature', &
ptr_patch=this%t_skin_patch, c2l_scale_type='urbans')

You can look at t_skin_patch in the code to see how it is calculated.

I recommend reviewing the literature for the best way to compare modeled temperatures to modis lst.

thanks a lot