Implement GaoOneill raw urban datasets and OlesonFeddema urban properties into mksurfdata_esmf. #1853
Conversation
| @@ -300,6 +301,48 @@ subroutine surfrd_get_num_patches (lfsurdat, actual_maxsoil_patches, actual_numc | |||
|
|
|||
| end subroutine surfrd_get_num_patches | |||
|
|
|||
| !----------------------------------------------------------------------- | |||
| subroutine surfrd_get_nlevurb (lfsurdat, actual_nlevurb) | |||
There was a problem hiding this comment.
Created 0.9x1.25 surface datasets and landuse timeseries for 1850, 1850-2015, 2000, 2005, 2015-2100 (SSP1-1.9, SSP1-2.6, SSP2-4.5, SSP3-7.0, SSP4-3.4, SSP4-6.0, SSP5-8.5) using mksurfdata_esmf.
You performed thorough testing using mksurfdata_esmf. Did you subsequently start a model simulation to confirm that your mods worked? I'm guessing that system testing would not work unless you also pointed to the newly created fsurdat files.
There was a problem hiding this comment.
Yes, I successfully ran a historical simulation (at least for 20 years, the simulation is ongoing) and pointed to the new surface dataset and landuse timeseries file in user_nl_clm. I didn't want to spend a lot of computer time running simulations for all of those scenarios. I'm also not that familiar with the tools system testing.
There was a problem hiding this comment.
Sounds good to me.
For system testing, I was referring to the ./run_sys_tests rather than the tools testing. Again, though, I wouldn't worry about it because many (most? all?) of the tests would require that you point them to your new fsrudat files.
There was a problem hiding this comment.
Sam should generate a temporary set of fsurdat files to run ./run_sys_tests
There was a problem hiding this comment.
Sam should generate a temporary set of fsurdat files to run ./run_sys_tests
IN PROGRESS: Generating all fsurdat files using mksurfdata_jobscript_multi
There was a problem hiding this comment.
Started cheyenne's test-suite pointing to the default fsurdat files (not, yet, the new ones that I'm generating). I realized that the old files already include nlevurb. Keith had made that clear in note (1c) above (sorry, I forgot having read that).
Tests are passing, though some differ from the baseline (dev090) because we're pointing to this new file as explained in note 1b above: CTSM52_tbuildmax_OlesonFeddema_2020_0.9x1.25_simyr1849-2106_c200605.nc
So now I'm rethinking the purpose of this test. I could rerun the test-suite without the new file from note 1b to confirm no diffs from baseline.
Then there's the new urban raw data (note 1a) going into the fsurdat files that I am generating. I vote against running the full test-suite for this. We have several new raw datasets coming with #1732 . I expect each one will lead to diffs from the baseline. I have not started generating new fsurdat files for the other new raw datasets. I prefer to do that once in the end for all of them. The complete generation of new surface datasets is time consuming.
I'm open to differing views.
There was a problem hiding this comment.
Discussed this with @ekluzek and agreed that the above approach is fine:
- Wait to generate new datasets once at the end.
- No need to rerun the test-suite with the old tbuildmax file.
There was a problem hiding this comment.
The cheyenne test-suite finished and two tests FAIL:
ERP_Ld9.f45_g37.I2000Clm51Bgc.cheyenne_intel.clm-default
ERP_Ld9.f45_f45_mg37.I2000Clm50FatesRs.cheyenne_intel.clm-FatesColdDefAllVars
due to temporary mods we made in Externals.cfg in the ctsm5.2.mksurfdata branch, so nothing to do with the GaoOneill branch of this PR.
|
@ekluzek I will go over Keith's PR with you in a quick meeting next week, before I merge with the ctsm5.2.mksurfdata branch. |
This comment was marked as resolved.
This comment was marked as resolved.
| @@ -1725,7 +1725,7 @@ lnd/clm2/surfdata_map/release-clm5.0.30/surfdata_ne0np4.CONUS.ne30x8_hist_78pfts | |||
| <stream_year_last_urbantv sim_year="constant" sim_year_range="1850-2000" >2106</stream_year_last_urbantv> | |||
|
|
|||
| <stream_fldfilename_urbantv phys="clm5_1" hgrid="0.9x1.25" | |||
| >lnd/clm2/urbandata/CLM50_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c160923.nc</stream_fldfilename_urbantv> | |||
| >/glade/p/cgd/tss/people/oleson/urban_sfcdata/Feddema_urban_data_080410/HIGH_RES_VERSION2/URBAN_PROPERTIES_THESIS_TOOL/JUN_22_2018/CLM50_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c200605.nc</stream_fldfilename_urbantv> | |||
There was a problem hiding this comment.
Comments from @ekluzek
- Better to rename the file
CLM52_tbuildmax_Oleson_2016_0.9x1.25_simyr1849-2106_c200605.nc
and is it still based on Oleson (2016) or a newer publication? - After that, Sam can copy to lnd/clm2/urbandata and run
rimportto get the file in the repository.
There was a problem hiding this comment.
Good point. I've rename the file appropriately:
/glade/p/cgd/tss/people/oleson/urban_sfcdata/Feddema_urban_data_080410/HIGH_RES_VERSION2/URBAN_PROPERTIES_THESIS_TOOL/JUN_22_2018/CTSM52_tbuildmax_OlesonFeddema_2020_0.9x1.25_simyr1849-2106_c200605.nc
There was a problem hiding this comment.
I've updated the file name in bld/namelist_files/namelist_defaults_ctsm.xml and pushed to the branch.
There was a problem hiding this comment.
Completed this "rimport"
There was a problem hiding this comment.
@slevisconsulting this file needs to be copied over to inputdata/lnd/clm2/urbandata so that it can be automatically downloaded. Having the full path allows this to run on cheyenne, but the general operation needs it to be under the inputdata directory structure.
There was a problem hiding this comment.
@ekluzek thank you. I copied the file correctly but neglected to explicitly say so by committing & pushing the relevant change in namelist_defaults_ctsm.xml because I still have to copy and rimport the transient urban files. Doing that next.
| @@ -97,7 +97,15 @@ | |||
|
|
|||
| <mksrf_furban> | |||
| <entry> | |||
| <data_filename>lnd/clm2/rawdata/mksrf_urban_0.05x0.05_simyr2000.c220127.nc</data_filename> | |||
| <data_filename>/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/PCTURB_GRID/Historical/urban_properties_GaoOneil_05deg_ThreeClass_2000_c20220910.nc</data_filename> | |||
There was a problem hiding this comment.
@ekluzek 's comment
Change to use %y also for the time-slice/baseline file to be consistent with the requested year.
There was a problem hiding this comment.
Assigning to @slevisconsulting
There was a problem hiding this comment.
Sam also needs to copy the new files to lnd/clm2/rawdata and run rimport
There was a problem hiding this comment.
./rimport -list urban_list.txt in progress
This means that we stop defaulting mksrf_furban to the yr-2000 file for years other than 1850 and 2005. Any timeslice year we ask for, we get the raw file for that year.
| @@ -97,7 +97,7 @@ | |||
|
|
|||
| <mksrf_furban> | |||
| <entry> | |||
| <data_filename>/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/PCTURB_GRID/Historical/urban_properties_GaoOneil_05deg_ThreeClass_%y_c20220910.nc</data_filename> | |||
| <data_filename>lnd/clm2/rawdata/gao_oneill_urban/historical/urban_properties_GaoOneil_05deg_ThreeClass_%y_c20220910.nc</data_filename> | |||
There was a problem hiding this comment.
@olyson @ekluzek
A heads up: When I updated the paths in this .xml, I missed that the file names now have the _cdf5_ label, e.g:
urban_properties_GaoOneil_05deg_ThreeClass_%y_cdf5_c20220910.nc
I am correcting this in #1732 which I consider the next branch to soon be merged in the ctsm5.2.mksurfdata branch.
This string should have gone in with ESCOMP#1853, but I missed it, so the latest ctsm5.2.mksurfdata branch tag will not work as is right now. The correction will come in with the next tag.
samsrabin
added
enhancement
Description of changes
Implementation of GaoOneill raw urban datasets and OlesonFeddema urban properties into mksurfdata_esmf.
Specific notes
1a. Incorporate new raw urban surface datasets for 1850, present day (2000, 2005), historical, and five SSPs (SSP1, SSP2, SSP3, SSP4, SSP5) developed primarily by @keerzhang1 from Gao and O'Neill (2021) and Gao and Pesaresi (2022). The urban properties (morphological, radiative, and thermal) in these datasets are described in Oleson and Feddema (2020). These datasets have PCT_URBAN calculated with respect to the total area of the gridcell (as discussed in #1716 ). Note that the SSP1 datasets have been assigned to SSP1-1.9 and SSP1-2.6 and SSP4 datasets have been assigned to SSP4-3.4 and SSP4-6.0.
1b. A new building temperature stream file is implemented. The values of maximum interior building temperature in this file are documented in Oleson and Feddema (2020).
1c. Code changes in CTSM and mksurfdata_esmf to read in nlevurb from the surface dataset instead of being hardcoded in clm_varpar.F90. This will ensure backward compatibility with older urban datasets (which have nlevurb=5 as opposed to the new datasets which have nlevurb=10).
Note that the paths to these files have been hard-coded to my directories because I don't have inputdata permissions.
Contributors other than yourself, if any: @keerzhang1 (Keer Zhang), @fang-bowen (Bowen Fang), @Face2sea (Lei Zhao), @billsacks (Bill Sacks)
CTSM Issues Fixed (include github issue #): #1445 #591
Are answers expected to change (and if so in what way)? Yes, urban quantities will change due to changes in urban fraction and urban properties and thus grid cell averages will be different for grid cells that have non-zero urban fraction.
Any User Interface Changes (namelist or namelist defaults changes)? Yes, changes to namelist_defaults_ctsm.xml (new building temperature stream file), namelist_defaults_ctsm_tools.xml (new year 2000 raw urban dataset), gen_mksurfdata_namelist.xml (new raw urban datasets).
Testing performed, if any:
Created 0.9x1.25 surface datasets and landuse timeseries for 1850, 1850-2015, 2000, 2005, 2015-2100 (SSP1-1.9, SSP1-2.6, SSP2-4.5, SSP3-7.0, SSP4-3.4, SSP4-6.0, SSP5-8.5) using mksurfdata_esmf.