Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
glemieux opened this issue Oct 3, 2024 · 14 comments
Assignees
Labels
done Issues whose closing PR is done but not yet merged (pending test re-run ok)

Comments

@glemieux
Copy link
Collaborator

glemieux commented Oct 3, 2024

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)

@glemieux glemieux added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Oct 3, 2024
glemieux added a commit to rgknox/ctsm that referenced this issue Oct 3, 2024
This is due to needing a new 16 pft historical flanduse_timeseries file.
See ESCOMP#2810.  Note this is the older fates harvest mode, not the newer raw
LUH2 driven modes.
@glemieux
Copy link
Collaborator Author

glemieux commented Oct 3, 2024

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

@wwieder wwieder removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Oct 3, 2024
@glemieux glemieux changed the title FATES needs a new 16 PFT historical landuse_timeseries file for ctsm5.3.0 FATES needs a new 16 PFT, 4x5 historical landuse_timeseries file for ctsm5.3.0 Oct 3, 2024
@rosiealice
Copy link
Contributor

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
Copy link
Collaborator Author

glemieux commented Oct 4, 2024

@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
Copy link
Contributor

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
Copy link
Contributor

wwieder commented Oct 5, 2024

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

@wwieder wwieder added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Oct 5, 2024
@slevis-lmwg
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Collaborator

ekluzek commented Oct 7, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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

@slevis-lmwg
Copy link
Contributor

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).

@slevis-lmwg slevis-lmwg added done Issues whose closing PR is done but not yet merged (pending test re-run ok) and removed next this should get some attention in the next week or two. Normally each Thursday SE meeting. labels Oct 7, 2024
@glemieux
Copy link
Collaborator Author

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

@slevis-lmwg
Copy link
Contributor

Sounds right to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
done Issues whose closing PR is done but not yet merged (pending test re-run ok)
Projects
Status: Done
Development

No branches or pull requests

5 participants