FATES needs a new 16 PFT, 4x5 historical landuse_timeseries file for ctsm5.3.0

[glemieux]

This came up while addressing #2783:

@ekluzek using ./xmlchange CLM_BLDNML_OPTS="-clm_demand flanduse_timeseries" --append I get the following error:

60 2024-10-02 13:37:59: ERROR: Command /glade/u/home/glemieux/ctsm-test2/bld/build-namelist failed rc=255
61 out=
62 err=ERROR : CLM build-namelist::CLMBuildNamelist::add_default() : No default value found for flanduse_timeseries.
63             Are defaults provided for this resolution and land mask?

Originally posted by @glemieux in #2783 (comment)

Definiton of done:

• @slevis-lmwg create the ctsm5.3.0 dataset needed
• rimport the new file(s):
  surfdata_4x5_hist_1850_16pfts_c241007.nc
  landuse.timeseries_4x5_SSP2-4.5_1850-2100_16pfts_c241007.nc
• Add the creation of this to the mksurfdata_esmf Makefile (this will be phased out eventually so add a comment about that to the Makefile)
• Add this to the namelist_defaults
• Add a test for this to the build-namelist tester
• Make sure there is a test for this in fates
• Make sure the new test works

@slevis-lmwg tracking sprint for this work in #2791

[glemieux]

Note that this is failing the FatesColdLandUse test which is currently only in the fates suite of tests.

[rosiealice]

FWIW, we are also in need of an ne30pg3 resolution 16 PFT dataset to run FATES in SE coupled mode, if anyone is in the business of running those scripts...

[glemieux]

@ekluzek I'm wondering if the issue is not that we don't necessarily need a 16pft version, just a historical 4x5. I only see SSP 4x5 timeseries in the namelist defaults. I had in the back of my head that we had an issue somewhere dedicated to having fates being able to handle 78 pfts as the default for all files, but I couldn't find a specific issue. Does that ring a bell to you? Looking around I found this comment #1505 (comment), but I'm not sure if that's the full story here as I don't quite understand the full scope of the read requirements.

[rosiealice]

Yeah, I was also thinking earlier that we could collapse the extra CLM crop PFT areas onto the FATES PFTs. That would maybe reduce the need for duplication of effort...

[wwieder]

Sorry, maybe we can clarify what is needed at the standup or SE meeting next week

[slevis-lmwg]

Yeah, I was also thinking earlier that we could collapse the extra CLM crop PFT areas onto the FATES PFTs. That would maybe reduce the need for duplication of effort...

We discussed at standup:
@rosiealice I was under the same impression, but @ekluzek clarified that this capability does not work for FATES.
We also decided with @wwieder that Erik and I need to push cesm3_0_beta04 work before most other things at the moment.

[rosiealice]

@slevis-lmwg do you mean it doesn't work already, or that it wouldn't work at all?

As I see it we would just need to expand the dimensions of the fates_hlm_pft_map variable to 78 x 12?

[slevis-lmwg]

@rosiealice I'm not familiar with this topic beyond what I relayed from the standup this morning; however, here are relevant issues that seem to overlap:
#1948
#1785
#1505

[ekluzek]

The change that's needed to be able to use 78pft surface datasets for FATES is talked about here: #1785 (it points to some of the ones that @slevis-lmwg points out above). So it doesn't work right now for FATES, but should be able to work with some effort.

So the 3 options are:

1. Use 16 pft files for FATES as we do now
2. Fix CTSM as in Refactor surfrd for FATES #1785 so that 78 PFT files can be used for fates
3. Change the mapping of FATES variables as outlined by both @glemieux and @rosiealice so that FATES can use 78-pft datasets (this has the advantage that it would just work for ELM as well)

The more datasets we need to support for FATES makes the first option untenable. We don't want to have a 16pft version and a 78 pft version for all resolutions. So one of the last two options is what we should do. We don't have a CTSM person that could do the second right now. So if someone in FATES could work on one of them that would be helpful.

In the short term we could make the 4x5 landuse timeseries 16pft dataset though.

[slevis-lmwg]

It will take me 5' to submit the job that will generate the 4x5 16pft landuse file, so I'm going ahead and doing it now.

Assuming all works as expected, you will find the file later today in /glade/work/slevis/git/mksurfdata_toolchain/tools/mksurfdata_esmf

[rosiealice]

Awesome! Thanks @slevis-lmwg. Tagging @mvertens so she can hold off on doing it ;)

[slevis-lmwg]

Running now:
File name surfdata_4x5_SSP2-4.5_1850_16pfts_c241007.nc and corresponding landuse file and you can track the progress in surfdata_4x5_SSP2-4.5_1850_16pfts_c241007.log

The SSP in the name just means that I'm making a landuse file from 1850 to 2100 (just to have since I'm making the file).

[glemieux]

We will need to add this to a PR to update the namelist default list correct?

[slevis-lmwg]

Sounds right to me.

[glemieux]

@ekluzek previously we explicitly set the flanduse_timeseries data location in the FatesColdLandUse user_nl_clm file. Should I do the same here, or should I update the namelist_defaults_ctsm.xml? My assumption is to do the latter give that the shell_script in that test mod is supposed to facilitate finding the correct version in the default list:

CTSM/cime_config/testdefs/testmods_dirs/clm/FatesColdLandUse/shell_commands

Lines 1 to 3 in 26b9aa7

	#!/bin/bash
	./xmlchange CLM_BLDNML_OPTS="-clm_demand flanduse_timeseries" --append

Is that correct? And if so, should the new entry look something like:

<flanduse_timeseries hgrid="4x5" sim_year_range="1850-2100" use_fates=".true." 
>lnd/clm2/surfdata_esmf/ctsm5.3.0/landuse.timeseries_4x5_SSP2-4.5_1850-2100_16pfts_c241007.nc</flanduse_timeseries>

[slevis-lmwg]

@glemieux that looks right to me, though see if it works on the first try :-)

Also looks as though I marked the issue "done" before I should have. Sorry about that.