New patch insertion method #1155
Conversation
|
I don't think there are any required dependencies either way. |
|
@ckoven I think this looks solid. We may also want to pre-multiply any constants into compiled constants in the new function. Compilers may already to it, but why not avoid math when possible. |
Updates default parameter file and adds improvements to understory survival This includes parameter file updates to the default grass allometry, distinguishes between canopy and understory leaf turn over and adds two new arctic shrub pfts
|
Plenty of diffs with base generated on this test: |
integrated flux error fix, merge
|
I decided to investigate the differences that we're seeing with non-landuse test cases and found what I think is ultimately a minor issue, but something that maybe should be addressed. I noticed that the diffs are happening immediately on the second timestep (i.e. the first timestep after initialization). Writing out the variables necessary for calculating the psuedopatch age and picking a random process, I found that the patch order was incorrect based on the calculated psuedo age. What I think is happening is that the new method flips the assumed order of the nocomp patches on a site via the psuedo patch age calculation. In the new method, higher pft numbers are associated with "older" patches (i.e. pfts 1 -> 14 go younger to older). This is in contrast to the way we initialize the patches which is to iterate starting at pft Lines 827 to 830 in f5bd625 and then insert the patches in that order: Lines 853 to 876 in f5bd625 Given that the initial layout is As such, the fix for this would be to either flip the initialization scheme or flip the psuedo patch age scheme. |
The current scheme assumes that "older" patches are lower in patch number index and "younger" patches are larger in patch number index.
|
Retesting just the |
|
Regression testing on derecho completed over the weekend. The results are mostly b4b, with the exception of the landuse and nocomp based tests, as expected. The satellite phenology only differ in the fieldlist per 147d411. @rgknox there is one issue in that the test location: |
|
Manually editing the ST3 test user namelist to remove |
Sort patches in a simple way that orders them by land use, no comp PFT, and age.
Description:
As part of #1116, I realized there is a simpler way to sort the patches that takes into account all of their continuous (age) and categorical (possibly LU and/or PFT) variables, without needing to have a lot of nested logic. This way the patches will be in some predictable order, which may or may not be important, but seems better than not having them in any predictable order. I separated this from the rest of #1116 and submit it here via a git cherry-pick onto main because it should almost certainly introduce non-B4B changes.
The idea is to make a pseudo-age that takes into account the various patch labels, and then sort by that. The pseudo age is to take some large number N that a patch will never be older than (10,000 years, nominally), and make the pseudo-age = LU * N**2 + PFT * N + age.
Collaborators:
Discussed with @glemieux.
Expectation of Answer Changes:
I would expect this to change answers.
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: