Should add variables needed to calculate NBP into bc_out data structure

[ckoven]

In order for the host models to be able to calculate NBP, we need to pass to the host models all of the carbon fluxes leaving the FATES system. Currently we aren't passing fire emissions, instantaneous carbon losses to the atmosphere during land use change (conceptually overlapping with fire), grazing losses, and possibly others to come in the future.

@rosiealice has added some of the speciated fire emissions in NorESMhub#7. This is also related: ESCOMP/CTSM#1045.

We have an old issue on this point in #163. Since that is so old, I'll bring it up here again via this new issue so that it is closer to the top of the queue, as it is becoming more salient now.

[ckoven]

Update: I've done some work to include these and I believe I now have NBP and related variables working. Will issue PRs once I confirm correct behavior under a new spinup case.

FATES branch: ckoven/fates@twostream-restart-bugfixes-shijiefix...ckoven:fates:nbp_diagnostics
ELM commit: ckoven/E3SM@012f9c0

[rosiealice]

Awesome @ckoven. Does getting this right still require the fire emissions being sent to the atmosphere, or is this exercise orthogonal to that?

[ckoven]

@rosiealice I'm not exactly sure, I think it sort of depends on what the goal is, I see at least three potential ones. If the goal is to hand fire emissions to the atmospheric chemistry code, then yes it is totally orthogonal. If the goal is to be able to output an NBP whose time integral equals the change in total ecosystem carbon, so that one can diagnose emissions from a concentration-driven ESM experiment, then the code I have does that I think. (Except I haven't added the FATES veg C into the TOTECOSYSC variable yet, I should do that and confirm conservation in the history variables.) If the goal is to be able to actually do CO2 emissions-driven simulations, then what I've done should work in ELM (I think) but not quite in CLM.

As I understand it, the ELM uses column-level nee as the thing it scales to the gridcell and passes to the coupler (see E3SM code here, so I think that what I have done in the above E3SM commit would then get handed off to the coupler.

For CLM, it looks like the variable that gets passed to the coupler is net_carbon_exchange_grc. I think the relevant lines of code are here. It is defining that variable via a bgc_vegetation_inst method though, which I don't believe is something that would be active in a FATES run. So some additional handling would be needed to pass the combined fluxes there. I should say that (a) my reading of this may all be wrong, and (b) now that I'm looking at the CLM code, I think that much of what I did in the ELM commit above will probably be somewhat different in CLM, because the underlying data structures have diverged.

[rosiealice]

Hi @ckoven,

Thanks for this! I have cherry picked your commits here into the NorESM FATES branch:

NorESMhub/fates@noresm...rosiealice:fates:nbp_outputs

For the CLM-side changes, just to be sure, it is the logic in this commit: ckoven/E3SM@012f9c0

that needs to be mirrored from the ELM implementation, right?

[ckoven]

@rosiealice I have a PR on E3SM at E3SM-Project/E3SM#7231 which handles all the ELM-side changes (and also an adjacent bugfix)