Various arrays we have are dimensioned by leaf layer. Leaf layer boundaries are defined by top-down depth integrated vegetation area, and controlled by the input parameters that define the starting bin width and an increase factor.
The issue is that when we determine the number of leaf layers there are in a cohort, if the cohort has more VAI than the last bin in dlower_vai, it will generate an index that is out of bounds for various arrays. See here:
I think there are at least two ways to improve this. We could increase the allocation of arrays that use this indexing to nlevleaf+1, or we could force the last index of dlower_vai to be very very large (like e+20) or something silly large.
Various arrays we have are dimensioned by leaf layer. Leaf layer boundaries are defined by top-down depth integrated vegetation area, and controlled by the input parameters that define the starting bin width and an increase factor.
These parameters define the array dlower_vai, set here: https://github.com/NGEET/fates/blob/main/main/FatesInterfaceMod.F90#L928-L937
The issue is that when we determine the number of leaf layers there are in a cohort, if the cohort has more VAI than the last bin in dlower_vai, it will generate an index that is out of bounds for various arrays. See here:
https://github.com/NGEET/fates/blob/main/biogeochem/EDCanopyStructureMod.F90#L2258
This is because dlower_vai is the size nlevleaf and so are the the arrays that use dlower_vai as its indexing... such as ts_net_uptake, see here:
https://github.com/NGEET/fates/blob/main/main/EDParamsMod.F90#L113 https://github.com/NGEET/fates/blob/main/biogeochem/FatesCohortMod.F90#L166
I think there are at least two ways to improve this. We could increase the allocation of arrays that use this indexing to nlevleaf+1, or we could force the last index of dlower_vai to be very very large (like e+20) or something silly large.