broadleaf_colddecid_extratrop_shrub starting with very high basal area

[jenniferholm]

Hi all,
I'm running some boreal simulations and when I include the broadleaf_colddecid_extratrop_shrub PFT (number 9 in the PFT list), in the first month of the first year the basal area is very high (300 m2/ha) and the individuals immediately start in 6th size class bin. This would be the 30-40 cm DBH size class. Weird!
In each additional time-step the basal area does lower, and stabilizes at around 30cm BA, which is probably still too high for shrubs. The shrubs always persist in this 6th size class bin and never progress from it.
So could this just be an indexing error? Maybe in the PFT/size indexing (SCPF) the first broadleaf_colddecid_extratrop_shrub should begin at index 105, but instead this PFT starts at index 110.

These runs are starting from bare ground, not using inventory data. Running with Hydro turned on.
In the same run I also include two boreal trees, and these trees grow from the lowest size class and onward as expected.

To the other folks that are running boreal simulations, have you come across this issue with colddecid shrubs?

I'm also wondering if this is an allometry issue. I am using different allometry coefficients from the default. I've gone through the BAAD database and determined new coefficients based on their data.
Another red flag is that DDBH in the outputs is always zero, which can't be right. So maybe something is off with "dddh" in the allometry module when calculating height. (For calculating height I'm using case 3, the 2 parameter power function.)

Any thoughts on what is causing this?

[ckoven]

Hi @jenniferholm, have you tried working through your BAAD-based allometry function to see what the DBH at recruitment should be, for the recruitment height of 0.75m? I'm assuming you are using the default values here: https://github.com/NGEET/fates/blob/master/parameter_files/fates_params_default.cdl#L968

[rosiealice]

That is weird indeed. Have you tried reverting one or all of the allocation parameters to check if that's the cause? (I guess you can do very short simulations of it happens right away). Either way, it seems like they are very oddly shaped shrubs...

[ckoven]

I wonder if it'd be—in the net—more helpful or just more complicated for this sort of thing if we overloaded the meaning of the fates_recruit_hgt_min parameter, such that if a value was negative then the code would interpret it as a diameter of recruitment rather than a height of recruitment?

[jenniferholm]

@ckoven - thanks for your suggestions, and I was using the default fates_recruit_hgt_min of 0.75m for this shrub. From a quick look at the database, it looks like this might be too high. I like your idea of solving for the inverse to find the DBH, and will do that.

I'd also like to put together a figure of initial height when DBH is low (and assume this is recruitment stage), just to see the range. BAAD also has age, and I can look into that data (but it might be more sparse).

Rosie - did you mean to say allometry parameters instead of allocation parameters? So reverting back d2h1, d2h2, etc.?

[rosiealice]

Yes, allometry, not allocation...

[glemieux]

Closing as this is due to allometry initialization. We've added an issue to the fate's user's guide repo to address this by helping users become familiar with the allometry tooling available: NGEET/fates-users-guide#14