cleaning up nocomp patch indexing

[rgknox]

Description:

This set of changes removes the need for all these checks that determine if a patch is nocomp+fixedbiogeog. We currently do this check because when in this mode, we construct a bareground patch in the zero-th patch index position. When we traverse patch loops, sometimes we increment the patch index, and this logic check makes sure that we don't increment.

However, we don't need to put this special bare-ground patch in the zeroth position. We can just put it in the first position, and allow it to be in-line index-wise with the what ELM/CLM identifies as the 1st vegetated patch. This is fine, FATES has patches in the full dynamics mode that have no cohorts, it's used to having patches with no vegetation lined-up with patches in CLM/ELM that are "vegetated". What happens is we set the weighting to zero, and many of the fluxes are some nominal value.

We also don't need to touch the ELM/ELM side of the code, because the way we create out weightings actaully works for both the indexing schemes described. Why? because we assign the CLM/ELM bare-ground patch fraction based on 1 minus the sum of all patches total canopy area, which doesn't care about index position.

Here are some slides that give a sense of what is going on and what is proposed: https://docs.google.com/presentation/d/1ZwErNVF3B-_jJwpCDud3d-MtR59Idax8YTWe_ErEc8Q/edit?usp=sharing

Further, if someone want's to bypass some subset of physics, or some algorithm, because there is no vegetation, it would be more appropriate anyway to compare against total canopy area, and not if it is a nocomp+bareground patch.

I still need to make sure that we don't exceed our patch counts on the fates-side when in nocomp+fixedbiogeog, in this mode we were using 1 less space as we matched with ELM/CLM arrays.

Collaborators:

Discussions with @glemieux

Expectation of Answer Changes:

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

• The in-code documentation has been updated with descriptive comments
• The documentation has been assessed to determine if updates are necessary

Integrator

• FATES PASS/FAIL regression tests were run
• Evaluation of test results for answer changes was performed and results provided

Documentation

• Technical Note update:
• User's Guide update:

Test Results:

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag:

FATES baseline hash-tag:

Test Output:

[glemieux]

We also don't need to touch the ELM/ELM side of the code, because the way we create out weightings actaully works for both the indexing schemes described.

For the hlm-fates interface mod, we skip the hlm bareground patch, col%patchi(c), by mapping fates patch index ifp onto hlm patch index p via p = ifp+col%patchi(c). If we make ifp=1 the bareground patch for fates, wouldn't we want to remove this mapping on the hlm side API?

[glemieux]

@rgknox and @glemieux to talk about this this coming Thursday.

[rgknox]

@ckoven and others.. Don't we need to allocate at least numpft patches for the secondary lu category (and others if nocomp is on?

[rgknox]

and actually, this shouldn't be a maximum here, it should not be more than fates_numpft, it should be equal to

[ckoven]

@rgknox there is logic in the nocomp x land use initialization that limits the number of PFTs allowed on secondary (or other LU) patches to be the number of secondary patches allowed, see here: https://github.com/NGEET/fates/blob/main/main/EDInitMod.F90#L554-L578

[rgknox]

I see, thanks for pointing that out @ckoven . Can you confirm that you do want to make sure maxpatches_by_landuse(primary) is greater than or equal to numpft, at this location in the code? The logic in the above mentioned line did not seem to ignore primary.