Potentially incorrect allocation to fine roots in PRTAllometricCarbonMod.F90?

[mpaiao]

I was looking at this code and it seems to me that allocation to fine roots would be underestimated:

fates/parteh/PRTAllometricCarbonMod.F90

Lines 543 to 555 in 70a3e13

	if( (carbon_balance > nearzero ) .and. (total_c_demand>nearzero)) then
	leaf_c_flux = min(leaf_c_demand, &
	carbon_balance*(leaf_c_demand/total_c_demand))
	carbon_balance = carbon_balance - leaf_c_flux
	leaf_c(iexp_leaf) = leaf_c(iexp_leaf) + leaf_c_flux
	fnrt_c_flux = min(fnrt_c_demand, &
	carbon_balance*(fnrt_c_demand/total_c_demand))
	carbon_balance = carbon_balance - fnrt_c_flux
	fnrt_c = fnrt_c + fnrt_c_flux
	end if

Carbon balance is subtracted after finding leaf_c_flux, and then scaled by fnrt_c_demand/total_c_demand, so the relative demand of fine root demand is applied in a lower carbon balance value. Shouldn't the code be something like the one below?

       leaf_c_flux    = min(leaf_c_demand, &
                        carbon_balance*(leaf_c_demand/total_c_demand))
       fnrt_c_flux    = min(fnrt_c_demand, &
                            carbon_balance*(fnrt_c_demand/total_c_demand))
       leaf_c(iexp_leaf) = leaf_c(iexp_leaf) + leaf_c_flux
       fnrt_c         = fnrt_c + fnrt_c_flux
       carbon_balance = carbon_balance - leaf_c_flux - fnrt_c_flux

[mpaiao]

And I think the same rationale applies to the block a few lines above.

fates/parteh/PRTAllometricCarbonMod.F90

Lines 485 to 506 in 70a3e13

	if (total_c_demand> nearzero ) then
	! We pay this even if we don't have the carbon
	! Just don't pay so much carbon that storage+carbon_balance can't pay for it
	leaf_c_flux = min(leaf_c_demand, &
	max(0.0_r8,(store_c+carbon_balance)* &
	(leaf_c_demand/total_c_demand)))
	! Add carbon to the youngest age pool (i.e iexp_leaf = index 1)
	carbon_balance = carbon_balance - leaf_c_flux
	leaf_c(iexp_leaf) = leaf_c(iexp_leaf) + leaf_c_flux
	! If we are testing b4b, then we pay this even if we don't have the carbon
	fnrt_c_flux = min(fnrt_c_demand, &
	max(0.0_r8, (store_c+carbon_balance)* &
	(fnrt_c_demand/total_c_demand)))
	carbon_balance = carbon_balance - fnrt_c_flux
	fnrt_c = fnrt_c + fnrt_c_flux
	end if

[rgknox]

I agree @mpaiao

[rgknox]

yeah, we should not be updating the carbon balance until both pools have calculated their fluxes

[jkshuman]

I also agree with you @mpaiao good catch.

[mpaiao]

I changed the code to set the fluxes of all pools before changing carbon balance. You can check the changes in my local commit: mpaiao@bdd5efc

I should just note that this causes a substantial difference in the dynamics. In my tests for the semi-arid site in Brazil, just switching this order caused evergreens to go nearly extinct during an extreme drought year (not necessarily a problem because I was running a tropical moist forest evergreen in a semi-arid site).

[mpaiao]

I also had the impression that the carbon allocation routine is rather complex. I wrote a simplified version that simply allocates the available carbon (storage + carbon balance) towards all pools, proportionally to the deficit of each pool, and if there is any remaining carbon then it allocates to growth. I put this subroutine as an option in PRTAllometricCarbonMod.F90 (link below)

https://github.com/mpaiao/fates/blob/bdd5efc377be5f681ce0266fad423787771741b8/parteh/PRTAllometricCarbonMod.F90#L928

Do you think this approach makes sense?

[rgknox]

I like simple, seems fine to have the alternative.
In the N & P enabled allocation scheme, we allow the user to define the order in which replace tissues. We could potentially merge our ideas and create a c-only version:
https://github.com/NGEET/fates/blob/master/parteh/PRTAllometricCNPMod.F90#L615