appropriately defining and preserving cohort counts per patch

[rgknox]

In the NGEET model team meeting, we brought up a concern about defining suitably large enough maximum numbers of cohorts per patch. This is not a duplicate of #248 (which was a software bug issue).

The problem: simulations that don't have a large enough maximum number of cohorts per patch, will be forced to fuse cohorts that are not very similar, which will lead to degraded/unrealistic dynamic.

A confounding factor: Cohorts can only be allowed to fuse if they are of the same PFT as well. So, in situations where there are many PFT's that co-exist in the same patches, we need an even larger number of maximum cohorts per patch, to accomodate the diversity of having all of these PFTs.

Another confounding factor: It would be overly wasteful to tie the maximum number of cohorts directly to the number of PFTs, as only some pfts will co-exist in a patch.

Can we discuss potential solutions to this?

[rgknox]

One solution: We define exceedance thresholds on fusion tolerance. During fusion, FATES will fuse cohorts until the total number is within the maximum allowed. It will first fuse cohorts that are very similar in size, but will slowly relax the tolerance on their difference until enough cohorts have been fused. We can generate warning messages, or graceful exits if the fusion tolerance exceeds certain values.

[ckoven]

For reporting, I sort of feel like nobody ever looks at the log files unless the model crashes, and so I think that a better solution may be to report the fusion activity and tolerances as history variables. As a first step, I'd propose that we add two new history variables to track cohort fusion: one would be the number of fusion events per day, and the second is the cohort fusion tolerance, summed over each fusion event in a given day. Both ought to be on a patch-age-bin dimension. That way one could calculate the monthly fusion-event-weighted mean fusion tolerance as the ratio of the two variables. At least this way we can have a better sense of whether and under what conditions the fusion criteria are being violated, and so we'd be better informed of the risks of putting fusion tolerance exceedance criteria into the code.

[rosiealice]

@rgknox Does the dynamic_fusion_tolerance do this already, or are you talking about some sort of different idea? I agree with you about the log file @ckoven. I think I need more coffee before I can fully throw myself behind the "monthly fusion-event-weighted mean fusion tolerance", but I think in general you are right.

[rgknox]

@rosiealice : you are right, when dynamic_fusion_tolerance reaches 100, we gracefully exit.