Are There Alternative Methods to Create 0.01° Regional Surfdata for CLM5.2 Without mksurfdata_esmf?

[kylin]

Hi all,

I am trying to build a 0.01° resolution regional surface dataset (surfdata) for the Qinling Mountains (105.01–111.51°E, 32.08–34.94°N) using CLM5.2 for regional simulations.

My goal is to first generate a CLM-compatible surfdata template based on default datasets, and then replace some variables (e.g., soil, LAI, land use) with my own high-resolution data.

Since I cannot use mksurfdata_esmf on my system, I am attempting an alternative workflow based on regridding an existing global surfdata file.

My current planned workflow is as follows:

Start from an existing global CLM surface dataset (e.g., 1.9° × 2.5° resolution).
Create a target SCRIP grid for the Qinling region at 0.01° resolution.
Prepare a source SCRIP grid corresponding to the original global resolution (1.9° × 2.5°).
Use ESMF_RegridWeightGen to generate a mapping file between the source and target grids.
Use NCO (ncremap) to remap the global surfdata onto the 0.01° Qinling grid, producing a regional high-resolution surfdata file.

My questions are:
1、Is this workflow a valid and recommended approach for generating a regional high-resolution surfdata file in CLM?
2、If my approach is not reliable, are there any other recommended methods for generating regional surfdata without using the mksurfdata_esmf tool?

 

[slevis]

Although not recommended, your method seems valid. I think you should try it; however, at first the model may return errors along the lines of certain things "not adding up to exactly 100" or similar. You will then need to iterate until you resolve all the errors. In the best case scenario your high res. file will work without error, but I would still check it very carefully for strange outcomes from the remapping.

 

[kylin]

Although not recommended, your method seems valid. I think you should try it; however, at first the model may return errors along the lines of certain things "not adding up to exactly 100" or similar. You will then need to iterate until you resolve all the errors. In the best case scenario your high res. file will work without error, but I would still check it very carefully for strange outcomes from the remapping.

So I just want to confirm: given that I cannot use the mksurfdata_esmf tool, would my current regridding‑based workflow be the most viable approach for generating the 0.01° regional surfdata file, and are there no better alternatives available?

 

[slevis]

To run with ctsm5.2 you could also generate fsurdat files with the older tool mksurfdata_map, which is available in ctsm5.1 and earlier versions. An advantage is that this tool is aware of all the model requirements, so you're less likely to encounter errors at model run-time. However, I do not know how well it handles this level of high resolution. You may find information about that in other threads in these Forums.

A disadvantage of using either one of the mksurfdata tools is that you need to generate "raw datasets" for your region that replace the default raw datasets that we provide with these tools.

What tool did you use to generate your low res. fsurdat file? Oh, maybe it's one of the default files that we provide.

 

[kylin]

To run with ctsm5.2 you could also generate fsurdat files with the older tool mksurfdata_map, which is available in ctsm5.1 and earlier versions. An advantage is that this tool is aware of all the model requirements, so you're less likely to encounter errors at model run-time. However, I do not know how well it handles this level of high resolution. You may find information about that in other threads in these Forums.

A disadvantage of using either one of the mksurfdata tools is that you need to generate "raw datasets" for your region that replace the default raw datasets that we provide with these tools.

What tool did you use to generate your low res. fsurdat file? Oh, maybe it's one of the default files that we provide.

I used ESMF_RegridWeightGen + ncremap to generate a 0.01° regional surface dataset (surfdata) for the Qinling Mountains from a global coarse-resolution surfdata file. I intend to use this file as a template into which I will later insert my own high-resolution data (LAI, soil organic matter, bulk density, slope, etc.). Below is my workflow.

Workflow steps:

1. Create target SCRIP grid (0.01° Qinling region)
   Used mknoocnmap.pl (from CTSM tools):
   ./mknoocnmap.pl -p 33.51,108.26 -n qinling -dx 6.5 -dy 2.86 -nx 651 -ny 287 -v
   Domain: 105.01–111.51°E, 32.08–34.94°N
   Grid size: 651 (lon) × 287 (lat) → 0.01° resolution
   Output: SCRIPgrid_qinling_nomask_c260505.nc
2. Obtain global source surface dataset
   Standard global 1.9°×2.5° surfdata: surfdata_1.9x2.5_16pfts__CMIP6_simyr2000_c170616.nc (LANDFRAC_PFT ≈1 over Qinling).
3. Generate source SCRIP grid (1.9°×2.5° global)
   Because the source grid is regular lat/lon (96 lat × 144 lon):
   ncremap -G latlon=96,144 -g SCRIPgrid_1.9x2.5.nc
4. Generate conservative remapping weights
   ESMF_RegridWeightGen --source SCRIPgrid_1.9x2.5.nc --destination SCRIPgrid_qinling_nomask_c260505.nc --weight map_global_to_qinling_weight.nc --method conserve --src_type SCRIP --dst_type SCRIP
5. Remap all variables to the regional grid
   ncremap -m map_global_to_qinling_weight.nc --sgs_frc=LANDFRAC_PFT -i surfdata_1.9x2.5_16pfts__CMIP6_simyr2000_c170616.nc -o qinling_surfdata_valid.nc
6. Normalize PCT variables
   After remapping, PCT_NATVEG+PCT_CROP+PCT_URBAN+PCT_LAKE+PCT_WETLAND ranged from 94.2 to 99.8. I manually normalized them using Python (xarray) to enforce a sum of exactly 100 for every grid cell:
   
   import xarray as xr
   ds = xr.open_dataset('qinling_surfdata_valid.nc')
   total = ds.PCT_NATVEG + ds.PCT_CROP + ds.PCT_URBAN + ds.PCT_LAKE + ds.PCT_WETLAND
   for var in ['PCT_NATVEG','PCT_CROP','PCT_URBAN','PCT_LAKE','PCT_WETLAND']:
   ds[var] = ds[var] / total * 100
   ds.to_netcdf('qinling_surfdata_fixed.nc')
7. Validation
   PCT_TOT after normalization: min=100.0, max=100.0 (floating-point error ±1e-13).
   LANDFRAC_PFT = 1 over the entire region.
   Dimensions: lsmlat=287, lsmlon=651, time = 12.

My questions:

1. Is this workflow scientifically reliable?
   As a fallback when the official mksurfdata tools cannot be used, can this surfdata file be correctly recognized by CLM and used for regional simulations?
2. Does manually normalizing PCT variables cause any side effects?
   I only adjusted the values of PCT variables while keeping their relative proportions. Will this break other consistencies in the surface dataset (e.g., with PFT percentages)?
3. Is it feasible to use this file as a template for replacing with my own high-resolution data?
   I plan to keep the grid coordinates, mask, and most low-resolution variables (e.g., soil texture) from the template, and only replace LAI, SAI, some PFTs, soil organic matter, bulk density, slope, etc. – for which I have high-resolution data.
   
   • Do I need to worry about physical consistency between replaced and non-replaced variables?
   • After replacing any PCT variables, should I re-normalize them again?
4. Can the replaced surface dataset be used directly for simulations? Will the remaining low-resolution variables (which I did not replace) affect my simulation results? For example, if I replace LAI with high-resolution data but keep soil texture at the original coarse resolution, will the model's performance be limited by the coarse soil data? Any guidance on interpreting results from such a mixed-resolution file would be greatly appreciated.

Thank you for your insights!

 

[slevis]

1. Your approach seems reasonable. Run a test simulation to confirm whether it works.
2. I'm not great at predicting problems before they occur :-)
I recommend running a test simulation to confirm whether it works.
3. It seems feasible. Similar to previous steps, you will answer these and other questions through trial and error. You will address issues as they come up.
4. Seems likely that this will work. Also, yes, most certainly the low resolution fields will affect your simulations. I do not have guidance.