V2 Land Use Change #1116
V2 Land Use Change #1116
Conversation
…nough patches for a given land use type to acomodate all PFTs prescribed
… logging and land use change
…ry and secondary PFT maps differ
Updates and fixes to history zeroing and flushing Includes fixes to how some multi-dimensional history variables are initialized. This also introduces a new flush all history subroutine, to be implimented as an API call in later HLM pull requests.
…already in the linked list
…ght into the list This handles cases in which only one pft needs to receive patch area from the buffer, but due to precision errors, following the splitting routine would result in a very small patch, technically above the reasonable math precision limit, being held in the buffer
|
Regression testing is showing mostly expected results, but I'm seeing an exact restart issues with two satellite phenology tests: |
|
It looks like the seed values for the base are either zero or unset and the restart is uninitialized everywhere:
Looking at the passing baseline I generated recently the ERS differences are always showing unset everywhere for base and rest: |
|
The exact restart satellite phenology issue noted above has been corrected per c9e7271. The majority of fates testmods with differences are those that engage fixed biogeography, which includes all satellite phenology tests and the pre-existing Looking at an older fates suite test from back on May 30 that compared d38bc59 against Their is a DIFF for the All other tests are B4B with expected |
|
The DIFF associated with the |
|
@ckoven what is your take on the DIFFs above, particularly for the satellite phenology test results? I'm seeing diffs in the first time step for these cases, which suggests the difference is due to the update in the way the patches are being initialized. Here are the DIFF values that I'm seeing for the first time steps.
I suspect the The test folder on derecho can be found at: |
This reverts commit bb3d58e.
|
I looked into this some more this morning to get a better sense of what the initialization in fbg modes look like (without landuse). The new way in which we initialize the bareground with this update creates a difference in the initial patch areas. With this change we directly reference the incoming HLM On @ckoven should we retain the old method of the bareground generation for nocomp+fbg (without landuse) given the above? Or do we feel this is more correct given that the hlm is saying there may not be bareground? |
|
Thanks @glemieux I was also just looking into this and not understanding why there would be a difference. Your answer makes sense to me. To me, the new logic makes more sense than the old logic: we shouldn't be making bare ground area if the datasets say not to, it makes more sense to me to rescale the existing PFT areas proportionally. But a larger problem remains if there are PFTs beyond the 14 that we have been using, that means that they are crop PFTs and we should be mapping those onto our crop-analog PFT(s). But that also seems to me like a subsequent development for after when this is merged. |
|
@ckoven I think the only thing that might be of concern here, or at least should be noted for posterity, is that this will result in slightly lower fates/biogeochem/EDPhysiologyMod.F90 Lines 1838 to 1845 in b8e4eee |
This pull request adds the capability to read a landuse x pft mapping file to then be passed to fates. It also refactors the use_fates_logging namelist option from a switch to a mode select. This update allows the user to select a harvest mode that provides the mass or area-based land use harvest rates from the LUH2 landuse timeseries dataset. The fates pull request associated with this update is NGEET/fates#1116 [non-BFB] for FATES
This pull request adds the capability to read a landuse x pft mapping file to then be passed to fates. It also refactors the use_fates_logging namelist option from a switch to a mode select. This update allows the user to select a harvest mode that provides the mass or area-based land use harvest rates from the LUH2 landuse timeseries dataset. The fates pull request associated with this update is NGEET/fates#1116 [non-BFB] for FATES
This PR represents the second set of changes needed for transient global land use change in FATES.
Description:
This is written on top of #1040, so the scope looks larger than the specific code unique to this PR. The added functionality here is mainly based around running in nocomp+prescribed biogeography mode. So in this configuration, each patch has two distinct categorical variables: land-use class and nocomp PFT class, and the code allows the total patch area associated with both of these to be time-varying, so that land use governs land cover. The basic idea is that the code in #1040 reads in a prescribed timeseries of land-use states and transition rates from LUH2, which determines the rate of land-use-change disturbance on any given day for any given patch, and which happens alongside the existing harvest logic, which determines the transition rate of primary -> secondary lands. The new code in this PR builds on that to allow time-varying nocomp-PFT areas in response.
The way this works is that the code reads in a land use : PFT mapping file, which determines, for every gridcell, what fraction of each land-use type is associated with each PFT. This mapping is (currently) time-independent. The underlying dataset for this comes from @lawrencepj1's files that form the basis of the CLM and ELM BGC-configuration model's land use change data and the current FATES nocomp PFT data. Using that data, this code reallocates nocomp PFT fractions during the disturbance routines for all newly-disturbed patches whose land-use identity changed due to either logging or land-use-change disturbance. So, e.g., if primary lands are converted into rangelands, the PFT areal fractions of the newly-disturbed patches shifts in response. And the nocomp logic subsequently only allows the relevant PFT to recruit on the newly-changed patch.
In addition to the core functionality, a bunch of other things are also included to make the system work in a more general way. Model initialization had to be substantially changed to extend the nocomp logic to multiple land use types, and I pulled out bare ground fraction as its own variable instead of having an index of zero as in the prior logic. I added a switch for potential vegetation mode (
use_fates_potentialveg) which allows for spinning up the model under potential vegetation (i.e. all primary lands). If a run with land use is initialized from the restart file of a run with potential vegetation, then there is logic to automatically apply all needed land use transition rates and logging from primary land to other lands on the first day of the simulation, so that the initial land use states align with the driving data (see #1080 for more discussion). The parameters governing the fates of dead material produced during land use change needed to be updated to allow for global simulations (#1084).This code is tied to E3SM branch https://github.com/glemieux/E3SM/tree/fates-landuse-pft, will coordinate PRs as this moves through the queue. The tool to regrid and reformat the land use : PFT mapping data is in #1107.
The basic functionality appears to work, though there are a few things that still need to be sorted out. But I wanted to post it now that the core code is hopefully there, so that people can start looking at it.
This represents hopefully the last major piece of code development needed to start allowing CMIP-class experiments with FATES in a prescribed biogeography configuration.
fixes #1061.
fixes #1084.
further progress along the plan lain out in #450 .
Collaborators:
Lots of discussion with lots of people, and written with support of @glemieux.
Expectation of Answer Changes:
In principle this might not be answer changing in all other configurations, but I wouldn't be surprised if roundoff level differences were introduced.
Checklist
If this is your first time contributing, please read the CONTRIBUTING document.
All checklist items must be checked to enable merging this pull request:
Contributor
Integrator
Documentation
Test Results:
CTSM (or) E3SM (specify which) test hash-tag:
CTSM (or) E3SM (specify which) baseline hash-tag:
FATES baseline hash-tag:
Test Output: