PotVeg surface dataset using the wrong Urban dataset

[ekluzek]

Brief summary of bug

The Potential Vegetation surface dataset:

/lnd/clm2/surfdata_esmf/ctsm5.2.0/surfdata_0.9x1.25_PtVeg_nourb_1850_16pfts_c240216.nc

is using the wrong urban input dataset. It should be using the zero-pct urban dataset rather than the standard one.

ncdump -h $CSMDATA/lnd/clm2/surfdata_esmf/ctsm5.2.0/surfdata_0.9x1.25_PtVeg_nourb_1850_16pfts_c240216.nc | grep urban
		PCT_URBAN:long_name = "percent urban for each density type" ;
		URBAN_REGION_ID:long_name = "urban region ID" ;
		:Urban_raw_data_file_name = "urban_properties_GaoOneil_05deg_ThreeClass_1850_cdf5_c20220910.nc" ;
		:mesh_urban_file = "UNSTRUCTgrid_3x3min_nomask_cdf5_c200129.nc" ;
		:mesh_urban_topography_file = "UNSTRUCTgrid_10x10min_nomask_cdf5_c200129.nc" ;

General bug information

CTSM version you are using: alpha-ctsm5.2.mksrf.21_ctsm5.1.dev168

Does this bug cause significantly incorrect results in the model's science? Yes!

Configurations affected: Just potential vegetation datasets

Details of bug

./gen_mksurfdata_namelist --potveg_flag --res 0.9x1.25 --start-year 1850 --end-year 1850

reports on the urban dataset twice:

cat surfdata_0.9x1.25_PtVeg_nourb_1850_78pfts_c240313.namelist | grep urban
  mksrf_furban = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/rawdata/mksrf_urban_0.05x0.05_zerourbanpct.cdf5.c181014.nc' 
  mksrf_furban_mesh = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/mappingdata/grids/UNSTRUCTgrid_3x3min_nomask_cdf5_c200129.nc' 
  mksrf_furban = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/rawdata/gao_oneill_urban/historical/urban_properties_GaoOneil_05deg_ThreeClass_1850_cdf5_c20220910.nc' 

[ekluzek]

@sophmaca is the one that found this issue.

[wwieder]

Thanks for finding this, @sophmaca. @slevis-lmwg does it make sense for you to address this? I'll assign you for now

[slevis-lmwg]

@ekluzek I added "next" but maybe we can resolve my question here:
You're working on the "clm6" PR #2417 in the 5.2 branch. Should I work on this one (#2420) and tag it before yours or after it?

[ekluzek]

@slevis-lmwg I'm not sure which one goes first. It largely depends on which is ready first. So work on #2420, and we'll touch base again when either of are ready for theirs to come in.

[slevis-lmwg]

As far as I can tell, the fix consists of two small changes in gen_mksurfdata_namelist.xml:

1. In the mksrf_furban section, remove the PtVg section (clearly it was already not doing anything)
2. In the main PtVg section, replace 1850 urban_filename with the "zerourban" file

The resulting namelist looks correct, so I am regenerating (job is waiting in the queue) our default resolution PtVeg file surfdata_0.9x1.25_PtVeg_nourb_1850_16pfts_cXXXXXX.nc to replace our previously generated ones.

@ekluzek I will refrain from ./rimporting the new file until we discuss whether/when I should do that.

[slevis-lmwg]

Due to the simplicity of the fix, I opted against opening a new PR and just pushed the fix as a commit to the ctsm5.2.mksurfdata branch (PR #2372):

1. @sophmaca this means that you can already update your checkout of the ctsm5.2.mksurfdata branch and try the instructions in Add ability of mksurfdata_esmf to create datasets that can be used for Paleo work... #578 again.
2. @ekluzek pls let me know if this calls for a new tag in the ctsm5.2.mksurfdata branch.

[ekluzek]

@slevis-lmwg go ahead and make a new tag to make the change more visible. Good work on getting this done so quickly that's awesome!

[slevis-lmwg]

Closing this issue as done.
I opened checkboxes in #2372 about remaking the potveg fsurdat file with the correct tag and ./rimporting that file.