Some logic fixes to nocomp and nocomp + fixed_biogeog

[ckoven]

This fixes things so that nocomp + fixed_biogeog works properly (it was crashing before during init) and also a fix for nocomp (it was allowing recruits on supposedly-disallowed patches).

I think this is why nocomp was super-slow before, because it was actually allowing and PFT to recruit on any patch. Now it doesn't.

In my head, I had previously thought that nocomp also implied fixed_biogeog. I realize now that it doesn't necessarily, and that the logic differs slightly between nocomp versus nocomp + fixed_biogeog. Anyway, all the various modes should work as intended now:

• fixed_biogeog: only lets a given PFT exist on a gridcell if the map says it can
• fixed_biogeog + nocomp: only lets a given PFT exist on a gridcell if the map says it can, and separates the gridcell into patch areas that each PFT can solely exist on based on the map areas
• nocomp: splits up the map to give every possible PFT the same amount of space on every gridcell in which that PFT can solely exist on.

I think, in general, fixed_biogeog + nocomp is what people will want to use, not nocomp on its own, so we should probably add a test for a fixed_biogeog + nocomp configuration.

Description:

Collaborators:

Expectation of Answer Changes:

This should be answer-changing in nocomp, and allow the model to pass a nocomp + fixed_biogeog test (it wouldn't have before). All other modes should be identical.

Checklist:

• My change requires a change to the documentation.
• I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
• I have read the CONTRIBUTING document.
• FATES PASS/FAIL regression tests were run
• If answers were expected to change, evaluation was performed and provided

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]

I suggested one minor refactor for simplicity, but this looks good as is.

[rosiealice]

I guess the crux of this is that the use_this_pft flag is a site level and not patch level quantity. I wonder
a) whether use_this_pft should be a patch level quantity.
b) if not, could we put a comment where it is calculated (or here) to explain why this patch-level logic is required in nocomp mode?

[ckoven]

@rosiealice I added the comment you requested above.

[glemieux]

All expected tests pass b4b, with the exception of a baseline DIFF for the one no comp testmod, which is also as expected. Test results are here:
/glade/u/home/glemieux/scratch/ctsm-tests/tests_pr805-nocompfixes

[glemieux]

@ckoven am I remembering correctly that you had suggested we add a regression test covering the use of both nocomp + fixed biogeography modes? If so, I'll add an issue on the ctsm-side and roll that into one of the ctsm-side cleanup PRs I have going.

[ckoven]

@glemieux yes please do add a nocomp+fixed_biogeog test into one of the CTSM PRs