NBP outputs

[rosiealice]

THIS IS NOT READY YET.

Description of changes

These changes introduce the capability for FATES to write NBP (net biome productivity) fluxes to the atmosphere, inclusive of fire, harvest, grazing and product pool decay carbon flux.

This code adds

1. A new wrap function (wrap_atmosphericfluxes) in clmfates_interfacemod.
2. A set of 'composite' fluxes defined in soilbiogeochemistrycarbonfluxesmod, to be used when FATES is active. These are in addition to those that are defined in cnvegcarbonfluxmod, but those are complicated to use when FATES is on as their history is not defined and they are not accessiable upstream of CNvegetationfacade (or, at least, I couldn't figure this out).

Still to add :
[] Balance check for the NBP fluxes
[] Logic for different modes of FATES.
[] Restart new variables if needed (pending tests)

This code is paired with: NorESMhub/fates#19

Specific notes

On the subject of balance checks, I am not sure that the current logic for balance checks will work as

• FATES accumulates GPP and NPP over the course of a day
• These contribute to NBP BUT
• They are not added to the vegetation pools until the END of the day.

In effect, the accumulated NPP is held in a 'virtual pool' in FATES until it is added to the vegetation. Potentially this could be counted as part of the total land carbon stock, but it is complicated. I will solicit inputs on this from the FATES team.

Contributors other than yourself, if any:
@ckoven

CTSM Issues Fixed (include github issue #):
NGEET/fates#163

Are answers expected to change (and if so in what way)?
Only to add the new output fields (FATES_NBP, FATES_NEP)

Any User Interface Changes (namelist or namelist defaults changes)?
No

Does this create a need to change or add documentation? Did you do so?
Maybe, but no...

Testing performed, if any:
(List what testing you did to show your changes worked as expected)
(This can be manual testing or running of the different test suites)
(Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide)
(aux_clm on derecho for intel/gnu and izumi for intel/gnu/nag/nvhpc is the standard for tags on master)

NOTE: Be sure to check your coding style against the standard
(https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review
the list of common problems to watch out for
(https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).

[rosiealice]

Balance Check Discussion Notes from FATES SE call.

We discussed the (numerous) timestepping issues related to the NBP/total land carbon exchange balance check. To summarize.

1. Some fluxes are generated in FATES and released over the course of the next day. These include fire and grazing. The impact of the fire, however, occurs at midnight, and so the mass is lost from the pool at that point (when the daily FATES call happens). Therefore we probably need a 'balloon' containing the fire emissions which empties as they are released over the course of the next day.
2. Other fluxes (product decay) occur natively on the CLM timestep and so this does not need to happen.
3. For NPP accumulation, the virtual NPP pool probably should be added to the total carbon state condition for the balance check. This will need to be updated in the fast timescale fluxes where site%gpp_acc is calculated.
4. There are unresolved issues for respiration, where the maintenance respiration flux is derived from this timestep, whereas the growth respiration is coming from the previous day. No-one is very sure how to deal with this or whether it matters.

[rosiealice]

The first thing to do here is to add the npp_acc pool and add it to the balance check with fire/grazing off. Then after that we can add the fire/grazing fluxes balloon to keep the 'burned but not emitted' co2 over the course of the day after the fire... (since we are always emitting yesterdays emissions, as fire is calculated at midnight -after- the day has passed).

[mvdebolskiy]

@rosiealice is is this needed for beta01?

[rosiealice]

It is needed for doing the emissions-driven simulations so I think it probably is. Though we can discuss. Just working through adding the balance checks.

[rosiealice]

This is superceded by #148