Add FATES land use change module to pass LUH2 data to FATES #2076
Conversation
FATES API update to facilitate fates refactor This updates a number of FATES type names and module use statements which correspond with a refactoring effort that moves FATES patches and cohorts into their own respective modules. With the FATES update is a minor science update, so there are changes to answers for FATES. This also incorporates a minor update to a more recent version of the ccs config external.
Rename hist fields to track them down more easily Renaming history fields to make easier to find in lists, e.g. when using ncview. For example, litter fields like MET_LIT and STR_LIT will be LIT_MET and LIT_STR.
Refactor some max_patch_per_col and maxsoil_patches loops As explained in issue 2025, the old loop structure was out-of-date and needed a refactor, partly because use of max_patch_per_col was limited, partly to simplify the code and make it easier to read and understand, and partly to improve (even if slightly) model performance.
ekluzek
added
enhancement
There was a problem hiding this comment.
@glemieux this is an exciting upgrade for CTSM/FATES so it's exciting it's starting to come in.
I have a few requests that I think should be straight forward and easy. Let me know if you want to meet to discuss.
I have one other question. How will the workflow to create these files work? I think we will add that to the CTSM5.2 Makefile right? And it will exercise FATES python scripts to make them right? That's something that we should discuss a bit...
|
@ckoven sorry I didn't get this until now. We had this slated as coming in after cross-seed dispersal as it was looking more complete. We might need to think about how to relay general FATES priorities to CTSM to make sure we are in sync. Something we are trying to do in CTSM now is bring things in that are ready to go. A goal with that is to bring things in ASAP when possible, and hopefully will get us bringing in PR's quicker than we have been. But, at the same time some work has a higher priority than something that is already ready to go. So we are going to need to balance between those at times. |
|
Thanks @ekluzek and no worries! |
|
Excited for this to come in. Thanks for working on it @glemieux and @ckoven . After this is merged, it seems like a logical next step to try and transient, historical no-comp baseline? I wondered if it makes sense for @samsrabin to do this run? We'll also likely need to start building up capacity to post-process results. These seem like high FATES priorities for the LMWG and I'm wondering how best to make them a reality? |
|
Thanks @wwieder — in principle I totally agree; in practice I think it might make sense to wait until the second set of land-use-change mods are ready, which I am still working on. Basically the set of changes in this PR provides the infrastructure for land-use change, but won't yet really be scientifically meaningful for a few reasons. The main one of which is that there is in this PR no enforcement of land cover properties on patches with a given land use. I.e. there is nothing that makes pasture lands or croplands behave differently from secondary lands here. In the short term, the way to accomplish this is (1) the linkage of the land-use classes with the nocomp logic, to enforce a different PFT composition on patches with different land use classes, and (2) starting to apply land management to the different land use classes, e.g. grazing on pasture and rangelands. In the long term, number 2 above can be expanded while number 1 can be relaxed, so that land cover follows more fully as a result of management rather than direct imposition of land cover (except in cases like crops where imposition of land cover is a direct land management practice). So once this first land-use PR is in, I have subsequent branches that will start to address both of those points, as well as other things needed to do transient runs such as the capability to spin up the model under potential vegetation, and then transition from that to historical land use. A less-fundamental but still relevant point is that we are working towards initial calibrated version of FATES in a nocomp configuration, but not yet a full-FATES version; so we don't have a parameter set to run through a global full-FATES with land-use transient run, but we are much closer to having an initial nocomp global calibration. So as part of this second set of land-use modifications, I do intend to do some global transient historical runs in nocomp configuration. |
Merging 2156 2148 2233 2235 2237 2044 For details please see the individual PRs and/or the ChangeLog. Multiple contributors, as listed in the individual PRs and the ChangeLog. Answers change for 3 tests: ERS_Lm20_Mmpi-serial.1x1_smallvilleIA.I2000Clm50BgcCropQianRs.izumi_gnu.clm-cropMonthlyNoinitial BASELINE ctsm5.1.dev151: DIFF SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm51Bgc.izumi_nag.clm-default--clm-NEON-NIWO BASELINE ctsm5.1.dev151: DIFF SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm51Bgc.izumi_nag.clm-NEON-MOAB--clm-PRISM BASELINE ctsm5.1.dev151: DIFF - The first is due to the bug fix in 2237; the diffs are in the fill patterns of 3 fields. - The second and third are due to the bug fix in 2044.
Use baset_latvary parameters Namelist parameters baset_latvary_slope and baset_latvary_intercept were never actually used, with values of 0.4 and 12 being hard-coded in the relevant subroutine instead. This PR fixes that, and also adds unit testing of a refactored function that uses them.
|
I should have noted NGEET/fates#1040 (comment) here instead; after discussing the carbon balance checking with @rgknox, we've realized that the wood product should not be included in the check for fates runs. As a result this has been removed via 1a1ec94. |
Various BFB fixes and updates Purpose/description of changes ------------------------------ the default comes in a later tag (slevis) Regular and python testing passed. Does not change answers relative to dev158.
|
@ekluzek Generating fates baselines prior to testing this PR branch with Also note that for |
@rgknox noted that the issue is that that one test for the previous fates baseline was rebuilt with the wrong fates version so that DIFF can be ignored. |
|
Ahh, good I'm glad @rgknox figured it out. I'll redo that baseline test. Sorry about that, that's my bad. |
|
I'm seeing failing RUNs with fates NEON testmods on izumi. The issue appears to be that the I'm testing non-fates NEON sites right now via the izumi |
I think I know what this is: in NGEET/fates#1040, the number of maximum fates patches per site went up by one (to 17) which sets the The simplest fix to align these is to update the new fates parameter file coming in with this PR to reduce the number of maximum patches back to 16. @ckoven does dropping the max number of patches for the primary landunit by one (to 9) sound appropriate? As an aside, @ekluzek should the I'm a little surprised that this passed on derecho. My guess is that since the dummy argument definition inside |
|
@glemieux offhand that does sound right to me. Do you want to look at the code together? Or do you want to put together the code changes you think should happen and have us look it over? |
|
@ekluzek the code change would be pretty straightforward, but it'll be easier to walk through it together given the code leading up to that point. The thing that I want to test out first is what the failure mode would look like when this fix is in. Let me give that a run and I'll tag up with you via chat later. |
A newer parameter file was generated that reduces the maximum number of fates patches for the default configuration. This avoids misalignment between the default surface datasets.
The wt_nat_patch array is allocated using surfpft bounds. While surfpft and natpft will typically match, this isn't the case for fates currently. As such the nag compiler will complain if the input array has lower bounds for its dimensions than the dummy argument bounds.
|
Status update: |
|
Regression testing the Izumi folder location: |
|
derecho location: A quick note that I needed to rebuild the Hat tip to @slevis-lmwg for pointing me to the fact that he was seeing the same thing as note with #2253 (comment) and that a resubmitted fixed his case. |
…ne at the model resolution and sim_year_range
Description of changes
This pull request adds a new module, the structure of which is adopted from the dyn_subgrid code, to enable hlms to ingest raw luh2 data to be passed to FATES. A new namelist variable is introduced use_fates_luh, to engage the module functionality, which is off by default. The luh2 dataset to be ingested is a minimally processed concatenation of the luh2 state, transition and management datasets.
The luh2 dataset is generated by the fates data tool found in NGEET/fates#1032. This pull request is associated with NGEET/fates#1040.
Specific notes
Contributors other than yourself, if any: @ckoven
CTSM Issues Fixed (include github issue #):
Fixes #1077
Are answers expected to change (and if so in what way)? No change expected for non-luh2 run modes
Any User Interface Changes (namelist or namelist defaults changes)? Yes, this adds a new set of namelist variables for the luh2 data file and
Testing performed, if any: Will do standard