v1 Land Use Change #1040
v1 Land Use Change #1040
Conversation
…ple receiver patches
…s (and secondary)
LUH2 transition and state information isn't dependent on the land use harvest capability.
Explicit-shape arrays need the parameter designation for named constants
I messed up the replacement string and dropped a character
Hydraulic failure mortality turned off for frozen soils Hydraulic failure mortality is turned off when any soil layer is below -2 degrees C. This should prevent high mortality of vegetation at high latitudes.
|
I've implemented a landuse testmod and I'm seeing a failure in the CNBalanceCheckMod.F90 during the first Note that this test is starting up from a cold start in year 2000. UPDATE: I can't seem to manually replicate the value of the error using the diagnostic outputs below. Calculating the cbalance error manually is far below the error threshold of |
|
Reviewing the carbon balance check for elm and clm, I found some inconsistency between the two HLMs. Discussing this with @rgknox, I've removed the wood products fluxes from the carbon balance check for both host land models in the respective HLM-side PRs. This results in the ctsm-fates landuse testmod passing. I've got a longer-term case running to check beyond the typical regression test length, which is usually no more than a year or so. |
|
Regression testing the fates suite on cheyenne is partially B4B with the following exceptions: These appear to be associated with testmods that activate disturbances and/or are long enough to elicit changes due to fire disturbance. The differences are very small at round-off level. This makes sense given that this PR changes the disturbance code as noted in the PR description. I'm still waiting on one test that is stuck in the queue, but that's a UPDATE: the last |
findloc is not available for the current supported compiler versions (e.g. < nag 7.0)
The sum of the maxpatches is used to set the natpft value in the HLMs. Some of the companion default surface datasets (e.g. NEON) currently assume 16 pfts for fates and as such, having the default paramfile with more pfts would require rebuilding many other surface datasets.
I also reordered the datestamp for the filename to YYMMDD
|
Regression testing the Retesting on derecho is underway. |
|
Testing on derecho is complete and results are similar to the previous results on cheyenne with small initial DIFFs showing up for the longer testmods: All other diffs are expected Derecho location: |
…5760) This pull request adds a new module, the structure of which is adopted from the dyn_subgrid code, to enable e3sm to ingest minimally processed 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. These changes also include a minor bug fix discovered in the process of developing the code, in which if the number of FATES patches being defined by the user in the fates parameter file is greater than the max_patch_per_col elm variable, would result in a BalanceCheck error. To be coordinated with NGEET/fates#1040 [nonBFB] for FATES
This pull request adds a new module, the structure of which is adopted from the dyn_subgrid code, to enable e3sm to ingest minimally processed 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. These changes also include a minor bug fix discovered in the process of developing the code, in which if the number of FATES patches being defined by the user in the fates parameter file is greater than the max_patch_per_col elm variable, would result in a BalanceCheck error. To be coordinated with NGEET/fates#1040 [nonBFB] for FATES
This PR is a first version of including land use change other than forest harvest into FATES.
Description:
The patch-level land use labels are extended from their prior values of only primary or secondary lands to also include pasture, rangeland, and crops. Land use change in FATES is treated as a disturbance rate (in area/time units) from existing patches with a given land use label to new patches with the new land use label. The code thus now has four distinct types of disturbances: treefall, fire, logging, and land-use change, any or all of which may occur on a given patch on a given day. The structure of the overall disturbance routines had to be somewhat changed to accommodate this new logic.
The code uses as its driving data the LUH2 state and transition data available at https://luh.umd.edu. The code in #1032 regrids this data into a new FATES land use driving dataset; i.e. it is decoupled from the existing code used to drive land use change in big-leaf CLM and ELM; this is because the logic is totally different, instead of translating land use to land cover offline, the land use data is directly ingested during runtime. The five FATES land use categories are aggregated during runtime from a greater number of LUH2 land use types (which include forest/nonforest, and multiple crops). The LUH2 state data is used to initialize the patch structure at the year of model initialization. The LUH2 transition matrix is used to drive land-use-change disturbance rates in FATES. During land use change disturbance, vegetation is either cleared or not cleared on the newly-disturbed patch based on the specific transition, following rules described in Ma et al (2020) https://doi.org/10.5194/gmd-13-3203-2020.
There are corresponding ELM- and CLM-side changes required to read and pass the LUH2 data to FATES, as well as a few other small things. This code is currently working with ELM, where a PR will be coming shortly.
This code only really handles the basic infrastructure of land use change, subsequent developments that have not yet been written are still needed to handle lots of other things:
Two new output history dimensions are created: (1) a land-use "
lu" dimension, and (2) a land-use x land-use "lulu" dimension. The former can be used for looking at any quantity across all land use types (area, biomass, etc); the latter can be used to look at, e.g., a disturbance rate matrix from a given land-use type to a given land-use type. Either as part of this PR (not yet done) or in a subsequent one, all of the existing history variables that are specific to secondary lands should be moved to the newludimension (see also #964, which also proposes a land use x PFT dimension, which would be useful).fixes #450.
fixes ESCOMP/CTSM#1077.
Collaborators:
I worked extensively with @glemieux in writing and testing this. Discussions with many people, including @rosiealice @jkshuman @adrifoster @lawrencepj1 @rgknox @jenniferholm @aldivi @sshu88 @JessicaNeedham @dlawrenncar @mpaiao @ekluzek @billsacks
Expectation of Answer Changes:
If land use is enabled, answers will be very different. If not enabled, roundoff-level changes would seem likely due to the reorganization of the loop structure in the disturbance code.
Checklist:
Test Results:
Currently not tested.
CTSM (or) E3SM (specify which) test hash-tag:
CTSM (or) E3SM (specify which) baseline hash-tag:
FATES baseline hash-tag:
Test Output: