CTSM5.3.0: New raw pft/lai/glc-behavior/soilcolor/fire datasets

[slevis-lmwg]

Description of changes

Updating gen_mksurfdata_namelist.xml, initially with temporary paths to the new raw data.

New surface datasets because of updates in PFT/LAI/soil-color datasets, as well as two fire datasets (AG fire, pearland and the glacier behavior dataset. Also bring in an updated "PPE informed, hand-tuned" parameter file. And turn on Li2024 fire method. Also updates to allow creating transient landuse timeseries files going back to 1700. Fix an important bug on soil fields that was there since ctsm5.2.0. This results in mkaurfdata_esmf giving identical answers with a change in number of processors. Add in creation of ne0np4.POLARCAP.ne30x4 surface datasets.

Asides: Remove VIC fields from surface datasets and testing. Add version to the surface datasets. Update the fire emissions factor dataset for the fire emissions testing in CTSM. Remove the --hires_pft option from mksurfdata_esmf as we don't have the datasets for it.

TODOs:

• 1700 fsurdat for TRENDY2024 spinup and
• 1700-2023 landuse file for TRENDY2024 historical
• Run ctsm5.2 spinup and historical as the control and
• Compare ctsm5.3 (aka TRENDY2024) to ctsm5.2
• Bring in new dataset from Bill (see below)
• @samsrabin @lifang0209: new peatland and AG fire peak month datasets to @slevis-lmwg (will move to streams later on in the ctsm6.0.0 cycle)
• @adrifoster: Table new population stream file for now. Adrianna explains, "it's formatted oddly and would be a pain to deal with"
• Update gen_mksurfdata_namelist.xml accordingly
• Bring in new code changes from Bill (See below)
• Before making any ssp landuse/fsurdat files, confirm that @lawrencepj1 has updated the raw ssp data
• Remove the hires_pft option (will add back in in ctsm6.1 with hires datasets)
• Remove the -vic option and special handling in Makefile, as well as remove vic tests (see Deprecate and remove the VIC-Hydro option #2597)
• Existing "make all" seems to have worked after a few corrections; took 6 hrs to run but did not include ultra high res in this iteration
• Get new PtVg (noAnthro) raw data file from Peter
• Move all new files and update temporary file paths to their final locations, then ./rimport:
  • new param file(s), new GlacierRegion, fire, NOT population
  • raw lake and urban files 1700-1849
  • raw urban 2016-2023
  • raw lai, soil color
  • raw pft and PtVg
• Table Sam R.'s tweaked mesh file; the hypothesis did not work for now fsurdat: PCT_SAND, PCT_CLAY, ORGANIC differ with different PE layouts on derecho #2502
• Resolve all of the ctsm5.3.0 milestone issues (https://github.com/ESCOMP/CTSM/milestone/19)
• @ekluzek to merge Add version to srf datasets slevis-lmwg/ctsm#8 to this PR
• Assess if we need other 1979 surface datasets -- Erik: No, since 1979 is only used for FHIST compsets so only need a landuse.timeseries file that includes 1979.
• make all the datasets with a tag (branch_tags/ctsm5.3.n02_ctsm5.2.027) from this branch
  • Since PLUMBER2 is on main now, we'll also need to recreate these surface datasets; @slevis-lmwg tested neon_surf_wrapper and plumber2_surf_warpper manually, and they worked. Open new issue: Via make all I get this error because we need to define an abs. path to the following file:
    No such file or directory: 'neon_sites_dompft.csv'
  • Make polarcap surface datasets in ctsm5.3.0, remove VR 1850 datasets #2720 Could also be completed after the 5.3 tag but ultimately we do want this in make all
  • Ability to run TRENDY type simulations on mainline CTSM  #2675 Same comment: could complete after 5.3 but want in make all
• @slevis-lmwg copy to final locations and ./rimport new fsurdat/landuse files (finidat done)
  • ./rimport -list ctsm5.3.plumber2.list
  • ./rimport -list ctsm5.3.neon.list
  • ./rimport -list ctsm5.3.synth.list
  • ./rimport -list ctsm5.3.list (after removing four VR grid 1850 fsurdat files because not needed)
  • copy to izumi's /inputdata area the files that failed to rimport (See New filesize limit for svn inputdata that restricts our larger ctsm5.3.0 files being rimported #2751)
• @samsrabin updates hillslope datasets Update hillslope testing fsurdat to 5.3 slevis-lmwg/ctsm#12
• @ekluzek updates namelist defaults of fsurdat/landuse/finidat files for all resolutions, compsets, etc to their final location (this includes adding the new default grids that appear in the [spreadsheet] (https://docs.google.com/spreadsheets/d/1Osq56e423CF107zhoNQ0VS7-iH_JXLF9AtCvBdXyfJ4/edit?gid=584342654#gid=584342654): Update surface datasets in namelist defaults slevis-lmwg/ctsm#10
  Date-stamps needing replacement in namelist_defaults:
  • fsurdat c240206 (NEON)
  • fsurdat/landuse c240216 (except the LUH2 file)
  • fsurdat/landuse c240221
  • fsurdat/landuse c240425 (T42, VR)
  • fsurdat c240613 (cidadinho) (Move this and Smallville to synthetic data directory?) Move Smallville data to ...clm2/testdata/ #2515
  • finidat: same list of finidats changed recently here
  • hillslope testmods Update hillslope testing fsurdat to 5.3 slevis-lmwg/ctsm#12
• @slevis-lmwg try clm_pymods: did not need to update datasets in /python/ctsm/test/testinputs
• Run aux_clm, address failures, including generating new finidat files with use_init_interp as needed
• Run ctsm_sci, fates, mosart, rtm
• See the checklist from 5.2, make sure we covered everything here too.
• Follow procedures in minor version update here: (https://github.com/ESCOMP/CTSM/wiki/Minor-Version-Update-Protocols)
• Erik would like to add a new file WhatsNewInCTSM5.3.md with a short description of what was updated since ctsm5.2

Specific notes

Contributors other than yourself, if any:
@lawrencepj1 @ekluzek @wwieder @adrifoster @samsrabin @billsacks @lifang0209 @linniahawkins @olyson

CTSM Issues Fixed (include github issue #):
Fixes #2723
Partly addresses #2720
Partly addresses #2752
Fixes #2452
Fixes #2570
Fixes #2618
Fixes #423
Fixes #2734
Fixes #2744
Fixes #2502
Resolves #2748

Are answers expected to change (and if so in what way)?
Yes, in generated fsurdat/landuse files.

Any User Interface Changes (namelist or namelist defaults changes)?
gen_mksurfdata_namelist.xml points to new datasets.

Testing performed, if any: will do release testing
In the first iteration generated new fsurdat/landuse files and ran the model (NCAR/LMWG_dev#59).
Second iteration in progress.
Now have updated datasets and verified with the build-namelist tester

[slevis-lmwg]

@lawrencepj1 I requested a review from you, but we could go over this together at our next "pft/landuse tools" meeting.

[slevis-lmwg]

UPDATE appears in #2570.

Also address #2617 with this PR.

[slevis-lmwg]

@slevis-lmwg @lawrencepj1 @samsrabin @ekluzek @linniahawkins discussed next steps for ctsm53.
@samsrabin took notes here:
https://docs.google.com/document/d/1-2LEjIhbs4j4NoythdLqdJ9A1pcNt4UJ_tyda2rrQWc

[slevis-lmwg]

Reviewing my own PR to include some reminders.

[lawrencepj1]

Hi @slevis-lmwg

Just to let you know that the raw PFT data for the SSPs rebased to TRENDY 2024 starting in year 2015 are available at:

/glade/campaign/cesm/development/lmwg/landuse_source_data/CTSM53RawData
globalctsm53TRSSP119Deg025_240728
globalctsm53TRSSP126Deg025_240728
globalctsm53TRSSP245Deg025_240728
globalctsm53TRSSP370Deg025_240728
globalctsm53TRSSP460Deg025_240728
globalctsm53TRSSP585Deg025_240728

I have checked them and everything looks good.
Peter

[slevis-lmwg]

Thank you @lawrencepj1

[ekluzek]

• @billsacks will give @slevis-lmwg a dataset for glacier regions by the end of this week.
• @billsacks will get code changes to @slevis-lmwg mid next week he will push directly to the branch

[ekluzek]

It looks like the file size limit is just shy of about 24GB as these are our current biggest files:

-rw-r--r-- 1 slevis cseg  24G Sep  9 15:24 surfdata_mpasa15_hist_2000_16pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 15:03 landuse.timeseries_C96_SSP2-4.5_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:47 landuse.timeseries_0.9x1.25_SSP5-8.5_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:46 landuse.timeseries_0.9x1.25_SSP4-6.0_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:45 landuse.timeseries_0.9x1.25_SSP4-3.4_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:44 landuse.timeseries_0.9x1.25_SSP3-7.0_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:43 landuse.timeseries_0.9x1.25_SSP2-4.5_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:42 landuse.timeseries_0.9x1.25_SSP1-2.6_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  25G Sep  9 14:41 landuse.timeseries_0.9x1.25_SSP1-1.9_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  26G Sep  9 16:08 surfdata_ne120np4.pg3_hist_2000_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  26G Sep  9 16:06 surfdata_ne120np4.pg3_hist_1850_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg  32G Sep  9 14:40 landuse.timeseries_0.9x1.25_hist_1700-2023_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg 114G Sep  9 14:59 landuse.timeseries_360x720cru_SSP2-4.5_1850-2100_78pfts_c240908.nc
-rw-r--r-- 1 slevis cseg 377G Sep  9 15:57 surfdata_mpasa3p75_hist_2000_16pfts_c240908.nc

Note, that for ctsm5.2.0 we have datasets up to 114G in svn inputdata with this one for example:

https://svn-ccsm-inputdata.cgd.ucar.edu/trunk/inputdata//lnd/clm2/surfdata_esmf/ctsm5.2.0/landuse.timeseries_360x720cru_SSP2-4.5_1850-2100_78pfts_c240216.nc

(Note, it also looks like we didn't rimport the ctsm5.2.0 mpasa3p75 dataset)

[ekluzek]

I tried an export of the 114GB file and that worked fine. So this is input rather than output.

I also replicated the problem in rimport (on the 32GB file) and also tried using "svn import" by hand and that also failed. So I've verified the problem.

From this discussion:

https://stackoverflow.com/questions/4976868/what-causes-svn-error-413-request-entity-too-large

It looks like it's a server side issue for Apache HTTP. Which means I think it's NRIT/CGD, so I'll send them a ticket.

[slevis-lmwg]

I reran these tests on derecho:
PASS make black and make lint
PASS ./run_ctsm_py_tests -u and ./run_ctsm_py_tests -s
PASS ./build-namelist_test.pl

I have submitted the following tests on derecho:

./run_sys_tests -s aux_clm -c ctsm5.2.028 -g ctsm5.2.029a
./run_sys_tests -s ctsm_sci -c ctsm_sci-ctsm5.2.014 -g ctsm_sci-ctsm5.2.029a
./run_sys_tests -s mosart -c mosart1.1.02_ctsm5.2.007 -g mosart1.1.02-ctsm5.2.029a
./run_sys_tests -s rtm -c rtm1_0_80_ctsm5.2.007 -g rtm1_0_80-ctsm5.2.029a
./run_sys_tests -s fates -c fates-sci.1.78.2_api.36.0.0-ctsm5.2.027 -g fates-sci.1.78.2_api.36.0.0-ctsm5.2.029a

[slevis-lmwg]

RTM test-suite OK
MOSART test-suite OK
aux_clm, ctsm_sci, fates still in progress

[slevis-lmwg]

Starting to go through test failures.

1. I'm finding that fsurdat files generated by subset-data are wrong, likely because I need to update the corresponding cfg file, so I'm starting with that.

[ekluzek]

@slevis-lmwg and @samsrabin it looks like the branch currently doesn't have the latest fire method turned on. And it looks like the spinup simulations didn't have it either.

Currently namelist_defaults has this:

<fire_method               >li2021gswpfrc</fire_method>
<fire_method phys="clm5_0" >li2016crufrc</fire_method>
<fire_method phys="clm4_5" >li2014qianfrc</fire_method>

I think it should be:

<fire_method               >li2024crujra</fire_method>
<fire_method phys="clm5_0" >li2016crufrc</fire_method>
<fire_method phys="clm4_5" >li2014qianfrc</fire_method>

[samsrabin]

Looks like that was listed in the first paragraph of this issue, but never actually put on the task list :-/

[slevis-lmwg]

@slevis-lmwg and @samsrabin it looks like the branch currently doesn't have the latest fire method turned on. And it looks like the spinup simulations didn't have it either.

@wwieder (cc: @olyson)
Regarding spinups, would you like me to repeat NCAR/LMWG_dev#65?

[ekluzek]

@slevis-lmwg to throw my opinion out there. I think we redo the simulations after we are done with ctsm5.3.0 as a tag and just use the current IC files that are finished. We need to redo the simulations, and have new IC files, but that can be a post ctsm5.3.0 tag. Since, we want to get ctsm5.3.0 done before Derecho goes down, we don't have time to redo the IC files now. My 2 cents...

I suppose you could start AD spinup now, to get partly done over the weekend though. But, probably OK to wait until the final tag to make sure there isn't anything else missing.

[wwieder]

I agree with @ekluzek here. let's focus on making the 5.3 tag and then when Derecho is back up we'll remake initial conditions (maybe even with CRUJRA that includes Antarctica!)

[slevis-lmwg]

With updates from troubleshooting tests (though not with the merge of slevis-lmwg#13):

I reran these tests on derecho:
PASS make black and make lint
PASS ./run_ctsm_py_tests -u and ./run_ctsm_py_tests -s
PASS ./build-namelist_test.pl

and I have submitted these tests again on derecho:

./run_sys_tests -s aux_clm -c ctsm5.2.028 -g ctsm5.2.029b
./run_sys_tests -s ctsm_sci -c ctsm_sci-ctsm5.2.014 -g ctsm_sci-ctsm5.2.029b
./run_sys_tests -s mosart -c mosart1.1.02_ctsm5.2.007 -g mosart1.1.02-ctsm5.2.029b
./run_sys_tests -s rtm -c rtm1_0_80_ctsm5.2.007 -g rtm1_0_80-ctsm5.2.029b
./run_sys_tests -s fates -c fates-sci.1.78.2_api.36.0.0-ctsm5.2.027 -g fates-sci.1.78.2_api.36.0.0-ctsm5.2.029b

• I hope that I fixed the first round, which was due to updates needed in the subset_data .cfg files.
• I still expect failures due to old finidat files needing to be replaced, and possibly other failures.