Carbon Biomass by Layer History Diagnostic

[rgknox]

Describe the issue

This issue documents two bugs, both associated with the two history diagnostics: FATES_CANOPY_VEGC and FATES_UNDERSTORY_VEGC.

Bug 1:
At line 2930 in FatesHistoryInterfaceMod.F90, we increment the site-level biomass for canopy trees by the product of plant density "n_perm2" and plant mass "total_m". However, "total_m" is total mass of the last chemical species (ie element) defined in the loop that closes above, on line 2855, and thus for CN or CNP runs will be not carbon but nitrogen or phosphorus.

The fix is to either 1) re-call total_m using the carbon12_element after the loop is completed, or 2) fill this diagnostic earlier in this sequence during the carbon12 portion of the element loop.

Bug 2:

We are filtering out cohorts from the calculation that are classified as "isnew". This filter is useful for other diagnostics, particularly flux diagnostics. A plant is classified as isnew=True if it was newly recruited in the most recent dynamics call, and thus has not had a chance to experience any fluxes yet. However, for diagnostics related to the state of the vegetation (structure, abundance, mass, etc), using this filter is misleading because we will always be missing the daily recuits. The affect on total biomass should be subtle in most cases.

FATES tag

sci.1.85.4_api.40.0.0

Host land model tag

irrelevant

Machine

irrelevant

Additional Note

This bug has no relevance to the CESM code freeze, as we do not run in CN or CNP mode with CLM (aside from synthetic testing environments).