Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

replace with high resolution raw data but frac_dst over 1

Fuhow

Fu Hao
Member
Hi ,
I am using CESM2.2.0 and CLM5.0, and I have recently been trying to replace the raw data for surfdata generation with high resolution raw data, to reduce the artifacts of output with high resolution grids. But even after I reference /cesm2.2.0/components/clm/tools/mksurfdata_map/READEME.developer, there are still some errors.

I take the ORGANIC data as an example, raw data in /inputdata/lnd/clm2/rawdata/mksrf_organic_10level_5x5min_ISRIC-WISE-NCSCD_nlev7_c120830.nc, gridfile in: /inputdata/lnd/clm2/mappingdata/grids/SCRIPgrid_5x5min_ISRIC-WISE_c111114.nc

Firstly, I wrote a high res organic nc file based on the variables and dimensions of mksrf_organic_10level_5x5min_ISRIC-WISE-NCSCD_nlev7_c120830.nc. Then, I ran the ./mknoocnmap.pl with my high resolution raw data grid infomation to produce a new SCRIP file, and put it in the inputdata path with the name of "SCRIPgrid_5x5min_ISRIC-WISE_c111114.nc".
1723392176964.png1723392227513.png

Then, I make surfdata with my destination grid,

./mknoocnmap.pl
./mkmapdata.sh
./mksurfdata.pl

However, although the map file from grid file based on high res raw data to my destination res grid file can be generated, but it shows frac_dst is over 1 in mksurfdata process.
1723393096419.png

I found that the mapfile in the process of surfdata shows that the raw file is global data, but my high-resolution data is regional, so I suspect that this is the reason of errors, am I wrong?
1723393057383.png

(Note, I just replaced my nc file with the original raw data file name, then replaced the newly made SCRIP with the pathname of the original grid file, and made no changes to the code process for mkmapdata)

Appreciate for any suggestions!
 

Fuhow

Fu Hao
Member
By the way, since frac_dst has a value between 1.9 and 2.1, I suspect that I did not define the dimensions correctly in high resolution raw data nc file, because I found that when I printed high resolution raw data nc and original rawdata, the longitude and latitude directions of the two data were reversed.
 

Fuhow

Fu Hao
Member
Update my process, I just recorrected my data's direction, since I found the direction of rows and cols correspond to the direction of longitude and latitude. But I still met the same error, I can only think about is there are something substandard occured during mkmapdata generation, dose my high res raw data for surfdata genration have to be global?
1723535168668.png
 

Fuhow

Fu Hao
Member
Hi, just another update, I have resolved the mksurfdata using own raw data issue I encounted, I think this is just due to the difference between the boundaries of the model output grid I defined and the rawdata grid I made, causing the differences between variables such as frac_dst, grid_corner_lat/lon to exceed the given tolerances. Therefore, I reduced the error by directly modifying the tolerance error.

For example, in mksurfdata_map/src/mkgridmapMod.F90.
1723690540662.png
It may be because all the previous rawdata are global scale data, and their boundaries are doomed to be [-180,180,-90,90], because I found that when making regional grid, there will be a reminder in mkmapdata.sh during mapfile generation:
1723691019043.png

However, simply expanding the margin of error is never a long-term solution, but producing high-resolution rawdata on a global scale means consuming a lot of computing power to produce surfdata. I came up with two ways to reduce this error, starting with a custom high-resolution rawdata and a defined model output grid defined in each other's format respectively. I'm going to try to define the model output grid in terms of rawdata first, but I think defining rawdata in terms of the output model output grid will make the process simpler.
 
Top