trimming, consistency in cold-start versus recruitment values

[rgknox]

I recently tried to turn-off trimming by setting trim_inc to 0.0. It generated unexpected results, in that the mean trimming value of the site continued to change over the course of the simulation. I even went into the trimming code and forced a bypass of it, to make sure that it wasn't triggering, and I still got the same result!

Here is what I found: When we initialize cohorts during EDInitMod cold start, we initialize the trimming to 1.0. However, cohorts are initialized with a trimming value of 0.8 during recruitment. So in my simulation, the memory of that first cohort to have a trim of 1.0 was simply fading away as it died out, making it look like the values were changing for individual cohorts.

Recruitment (create cohort):
https://github.com/NGEET/fates/blob/main/biogeochem/EDPhysiologyMod.F90#L2782-L2785
Recruitment (initial value): https://github.com/NGEET/fates/blob/main/main/EDTypesMod.F90#L45

Cold-start (create_cohort): https://github.com/NGEET/fates/blob/main/main/EDInitMod.F90#L1450-L1453
Cold-start (canopy_trim): https://github.com/NGEET/fates/blob/main/main/EDInitMod.F90#L1241

I talked a little bit about this with @ckoven , and we came up with a better system. Firstly, there should only be one initial trim constant, and it seems appropriate that would be 1. If it was supposed that there was too much or too little leaf biomass on a recruit plant, a better mechanism of addressing that would be to modify the allometry function, and not alter the initial trim constant.

Further, we already have capacity in the code for recruits to learn initial fineroot-to-leaf ratios over the course of the simulation (nutrient enabled runs only), where we keep a running average of that ratio for the smallest plants in the simulation for both understory and exposed (canopy). We could apply that same concept to trimming.

[rosiealice]

Thanks @rgknox. I agree that that is unusual behaviour. Is the broad idea here to replace the trimming logic with some kind of dynamic allometry scheme? I guess in some ways you can think of it a bit like a variable d2bl1, but maybe it would indeed be preferable to have this as a more biologically interpretable algorithm?