nutrient dynamics v2 of allocation and acquisition

[rgknox]

Description:

This set of changes brings in version two of nutrient dynamics acquisition and allocation. Specifically, this algorithm evaluates the relative state of carbon and nutrient stores in the plant, and uses that to allocate more or less fine-roots. Fine root biomass increases and decreases act as a proxy for activity, and therefore respiration costs.

This will be paired with a ctsm and e3sm pull request. The e3sm code is written but no PR. The ctsm side code is not written. I expect that code refactors to how FATES interacts with CTSM BGC will be implemented either prior to this, or in concert with this PR.

This branch of E3SM is compatible with this work, and will be organized into a PR as this one makes progress:
https://github.com/rgknox/E3SM/tree/rgknox/lnd/update-suppl-fates-uptake-api24

This PR with CTSM should be synchronized, and is an API change: ESCOMP/CTSM#1874

Collaborators:

@ckoven Xinyuan Wei @walkeranthonyp Jinyun Tang Qing Zhu @jenniferholm @dmricciuto Xiaojuan Yang

Expectation of Answer Changes:

This will change answers in nutrient limited simulations, ie parteh mode 2

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:

[rgknox]

There's two features in this PR related to history that should be pointed out:

1. A new history dimension was added "CLSZPF". This is canopy layer x size-class x functional-type. I added to to track the L2FR variable, which seems to vary by all three axes. Example of its definition is here: https://github.com/NGEET/fates/pull/880/files#diff-03feca0f1df8d3791c0d8f7b6055a0368d5241716d19d6a97c3d227fd6c5ad23R5350-R5354

2. A new history routine was added, update_history_nutrflux(). This updates history output for nutrient fluxes, prior to disturbance, which prevents the need to remember these fluxes and rescale them when patch areas change. Personally I like to see us expand this type of thing. There are other examples of fluxes that we save in a special array just for its diagnostic, to prevent its scaling when patch areas change, when the easier/simpler solution is to just update the history arrays themselves prior to disturbance. Here is the routine: https://github.com/NGEET/fates/pull/880/files#diff-03feca0f1df8d3791c0d8f7b6055a0368d5241716d19d6a97c3d227fd6c5ad23R1747 and here is the call (during ed_integrate_state_variables ) https://github.com/NGEET/fates/pull/880/files#diff-873439f6e1a0575bdcd8784eb63e6f1c65347c75a6598e8d169e40c2e8fb2090R553-R556

[walkeranthonyp]

Looks fantastic Ryan, great job. A few comments related to RD demand calculation and the /c costs of Nfix. Plus a couple re output variable naming conventions.

[walkeranthonyp]

How come plant_demand for N is calculated using only the Vmax for NH4. Wouldn't it make sense conceptually to include the Vmax for NO3 as well? ... That said, for the same Vmax values the RD simulations already take up a lot more N than the ECA simulations (in the FACE site simulations anyway).

[rgknox]

Good question. RD wants the plants to present a joint unified demand on nitrogen uptake. It does this because the demand is used to drive NH4 uptake, and then the remainder is applied to NO3. Thus with only one demand, we use only one parameter vmax_nh4.

However, we don't have to do it this way. ECA needs the vmax differentiated for NH4 and NO3. It might be cleaner if we have the vmax parameters the same for both RD and ECA. But, in the case of RD, we will simply add them together...?

[walkeranthonyp]

Yeah, I was expecting to see the sum of NO3 and NH4 Vmax multiplied by the root mass to get the whole plant demand. Just based on the concept.

That would increase plant competitiveness versus microbes in RD. I'm not sure what that balance looks like currently. But with RD in the FACE simulations, plants take up equivalent levels of N to ECA at much lower Vmax values, at least an order of magnitude lower Vmax if not more. That makes sense as RD and ECA are fundamentally different approaches, it's unlikely that with ECA N uptake is operating near Vmax for much of the time.

So while conceptually it makes sense to add them, it will further increase plant competitiveness and further widen the gap between RD and ECA uptake magnitudes for the same Vmax values.

[rgknox]

Yeah, the meaning of the vmax parameters for RD are much different than with ECA. Right now there is just no way around it, because RD applied the same demand sequentially to the NH4 and then to the NO3. Whereas ECA applies the two different demands NH4 and NO3 separately and exclusively to their parameters.

After this PR, we can re-evaluate how we form the NO3 demand from FATES to RD. We could apply the demands in RD independantly. But I would like to do it as a separate thing because it would require some non-trivial coding, particularly because that code assumes there is only 1 joint n demand term.

[walkeranthonyp]

Where does this temp-driven variation in C costs of N fix come from, is it a pub?

My concern here is that it might over-estimate C costs at higher temp. Here's my line of reasoning. The C cost here is the cost of doing work, i.e. metabolic N fixation. The rate of that metabolism is increased by temperature, so respiration increases but so should N fixation shouldn't it? So the cost of the work per unit N fixation doesn't necessarily increase, but it's the overall metabolic rate that increases so that both C loss and N fixation increases per unit time. Does that make sense?

Rather than a strong evidence base, this comes more from a general theoretical hunch I have that in model world we too often think of respiration only as a cost and don't consider the benefit of whatever process is using that energy. Yes, T increases respiration but that represents a general increase in metabolic rates.

Happy to discuss further and look at the evidence but I can't find that Houlton et al 2010 paper referenced for the parameters in this function.

[ckoven]

@walkeranthonyp This comes from eqn 3 in https://doi.org/10.1029/2009GB003621.

[walkeranthonyp]

Thanks @ckoven -- ahhh, I see. I hadn't looked closely at the form of the function. I'd assumed it was some relative of Q10 or Arrhenius but this seems much more reasonable.

[walkeranthonyp]

why is it just the vmax_nh4 variable that's had the eca_ prefix removed?

[rgknox]

this is because the vmax_nh4 parameter is used for both eca and rd, while the vmax_no3 parameter is just used for eca. Again, it might be better to use both to define demand for RD, as a sum.

[walkeranthonyp]

Not sure what the convention is here but I would encourage and underscore in between REC and L2FR. Thinking about it, I also would encourage a more bigendian type approach going from the broadest category to the more finer detailed, so putting REC after USTORY, so FATES_L2FR_USTORY_REC_PF. Above as well.

I guess there are lots of ways you could slice this but definitely encourage the _ no matter what :)

[rgknox]

I might had been worried that the var name was going to get too long and chopped by the host models. But I can at least try adding an underscore to see if it works, it would be nicer.

[walkeranthonyp]

Suggest NFIX_SYM also line 5412 below.

Also for free-living Nfix too. NFIX_FREE or whatever it is, but that way what you see first with both of them is that it's Nfix.

[walkeranthonyp]

Just an observation that fluxes tend to have the element first, e.g. PUPTAKE while stores tend to have the element second, e.g. FROOTN.

[rgknox]

Through discussions with @walkeranthonyp in this thread, I modified some parameters. Now, the potential nutrient uptake rates per unit fineroot biomass parameters, (vmax), have the same parameter names for use in rd and eca. See here:
https://github.com/NGEET/fates/pull/880/files#diff-91857484d2b9a65d2cb5a44ecfc1614fbc9567fede7867365cdc42502faa13f0R1007-R1012

Note also, that RD will now use the sum of the NH4 and NO3 vmax terms. So users who have been using this branch with RD, should halve their NH4 and NO3 parameters (previously it just ignored the NO3 term when using RD).

All changes to the parameter file are encapsualted here: https://github.com/NGEET/fates/blob/fa8841e24a761f5fef6a769e7fe3c63312d7417e/parameter_files/apichange_24to25.xml

[rgknox]

loaded the new parameter file onto cheyenne and imported

fates test suite running: /glade/scratch/rgknox/tests_1128-200653ch comparing with fates-sci.1.60.2_api.24.2.0-ctsm5.1.dev112

[rgknox]

Initial tests are showing differences compared to base in the FATES_LITTER_OUT and FATES_CBALANCE_ERROR, no other differences detected so far. Here is how the fates_litter_out diagnostic is constructed:

https://github.com/NGEET/fates/blob/main/main/FatesHistoryInterfaceMod.F90#L3485-L3490

In this PR, effluxes from the plant (due to excess carbon) are added to the litter fragmentation flux, where in main they were not. This is also reflected in the error term, as they have the exact same difference as the fragmentation flux.
These are typically very small, and from the test results, are very small. Honestly, I forget why I did this (but Ryan from the past may have had a good reason!). I think its because it made it cleaner to track carbon conservation between the host and fates.

[rgknox]

I finished going through the fates test suite results, and confirmed that differences were only associated with the change in the carbon efflux error term, and how that is exported to the litter flux (expected and part of this PR). Expected exeptions to this were in the PRT2 test (which should be different, the module was completely changed) and those tests already flagged with expected failures.

test dir: rgknox/tests_1130-082657ch