site-level mass flux accounting part 2

[rgknox]

Description:

This PR seeks to generate more consistency with how we track and restart some site-level mass fluxes. These mass fluxes are used for multiple purposes: run-time mass balance checks, history diagnostics and boundary conditions. So these fluxes needed a little attention in how they are used.

This PR is based on and should follow: #1448

Collaborators:

@glemieux @ckoven

Expectation of Answer Changes:

No answer changes, but it should fix restart errors with E3SM mass_balance_error diagnostics.

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
• FATES-CLM6 Code Freeze: satellite phenology regression tests are b4b

If satellite phenology regressions are not b4b, please hold merge and notify the FATES development team.

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:

[rgknox]

Making a note that we should add a comment units fix originally posted #1474

[maritsandstad]

Sorry, I made #1474 by accident, but I guess FYI the actual PR I meant to make for our NorESM side stuff is here NorESMhub#31 with a bit of discussion for background, that include fixing the comment also for grazing which is wrong in the same way presumably for the same reason

[glemieux]

Looks good. I only have one question that might be more for my own education. Otherwise this is good to go from my perspective.