Allometry Parameterization Issues

[rgknox]

Allometry parameterizations need attention, as a community. I think we need some coordination so we all get a sense of where we are and where we are going.

The "default" fates parameter file is about to roll out with 13 global PFTs. Keep in mind that the only reason we are releasing this global file right now, is because it by leaps and bounds improves our ability to find bugs and prevent headaches for everyone doing global runs.

The "default" fates parameter file should have a base assumption that it is scientifically invalid, unless the scientist using it modifies it or proves otherwise. Its just for testing, that is all. We have made some tweaks here and there, but that was only for convenience of some requesting scientists.

Some issues to point out:

• The tropical broadleaf evergreen allometry we currently seem to all be using (height-dbh, AGB-dbh, leaf-dbh, etc) uses old functional formulations (Saldarriaga, Obrien) that have significant differences with other modern approaches (Chave, Martinez-Cano, Lescure, Calvo-Alvarado, etc). Not that one is better or worse, but they are all very different. *I've put some time into this, but have not had the time to do sensitivity analysis, or robust intercomparison

• The tropical broadleaf evergreen we currently use has parameter assumptions that very likely, have large impacts on dynamics, and we have not really consolidated analysis to many of these (dbh_maxheight, dbh of maturity (seeds), the intercepts and exponents of the leaf to diameter relationships and how they relate to crown area, to name a few)

• Grass allometries need exploration/attention at both the functional-form and parameter level (for example, all grass allometries that I've seen people using assume same allometry as a hardwood tree, and thus have structural biomass, they end up being shrubs not grasses).

• AFAIK, we don't really have any team members using/developing allometric relationships for non-tropical PFTs (although there has been tremendous progress on getting closer and closer to reasonable global PFTs in general, thanks to @jenniferholm )

[huitang-earth]

@rgknox and @rosiealice I have been testing CLM5-FATES using 14pfts (including c4 grass) for the northern high latitude region. We are planning to develop parameters for some boreal PFTs in FATES and will be happy to contribute to the fourth aspect of the issue later.

In addition, I indeed encountered several problems with grass pfts and their allometry parameterization:

1. Since C4 grass is included, I found that the index in "FatesPlantRespPhotosynthMod.F90" at line 356 and 359:
   "bbbopt(nint(c3psn(ft)))" will become "bbbopt(0)", if it is C4 grass.
   This is inconsistent with the "bbbopt" defined earlier in the file at line 206:
   "bbbopt(2) = ED_val_bbopt_c4 (c4 grass)"

2. At some point, the model complains and stops, because:
   "Plant Growth Integrator could not find a solution in less than 300 tries"

   This turns out to be related to the grass pft and the structural biomass:
   "disparity in integrated/diagnosed structural carbon
   resulting from the on-allometry growth integration step
   bdead (integrated): 21.6991205402808
   bdead (diagnosed): 20.5541962311044"

   I notice that there is a comment in "EDPhysiologyMod.F90" that
   "For grasses, if leaf biomass is larger than target, then we reset dbh to match"

   But I did not see the code dealing with this. I just tried to reset dbh for the grass pfts similar to the woody pfts (based on structural biomass). It works OK.
   But according to your suggestion in this issue, if the structural carbon pool for grasses can be set to 0, perhaps, the problem can be better solved? I will be happy to test this in the code, If you think this is the correct way to go,

3. With regard to your issue updates to the parameter file #347, I am wondering why C4 grass is not included as a default pft in the new parameter file? Am I right that C4 photosynthesis has been included in FATES?

[mdietze]

PEcAn has an allometry module for calibrating allometeric relationships that can synthesize both raw data and existing equations (as often the raw observations for older papers is not available). By default it's connected to the USFS Jenkins allometry database, which should help a lot with you need for non-tropical trees. There's an R vignette explaining how to use it: https://github.com/PecanProject/pecan/blob/develop/modules/allometry/vignettes/AllomVignette.Rmd

[rgknox]

Thanks for the feedback @mdietze and @huitang-earth .

@huitang-earth :

1. thanks for pointing out that issue with the indexing, lets make a formal issue and get that fixed
2. Regarding the errors in carbon integration. There are two things going on here. First is that there is a new integration scheme, and this scheme has a maximum step error tolerance, while previous schemes did not. The simple answer to this is that you can increase the error tolerance by changing the parameter: max_trunc_error in that same scheme. Setting that value higher should make the integration more likely to complete, and while it does have an effect potentially on accuracy of carbon partitioning during growth increment, it does not effect mass conservation, and the allocation scheme in general is somewhat self correcting.

Also, grasses ideally shouldn't really have structural biomass, ie fates_param_allom_agb1 should equal 0. But we have all been allowing it some for various reasons, up to now. Soon we will put a logical check in the parameter checking algorithm to not allow it and query the user. Right now we allow it, because we have also had to make some fixes in other parts of the code to allow plants with no structure (still some testing needs to be done). As you pointed out, the current allocation scheme does perform some corrections to DBH, to keep plants tied to their allometric target structural carbon, but this only is supposed to work on non-grasses because grasses don't have the structure pool to tie into dbh.

So, another thing you might want to try is either changing your grass to have a very low value of fates_param_allom_agb1, and set the flag fates_param_woody flag to flag its a tree. Or, better, set that agb1 intercept to 0, and give it a test. Also, feel free to open an issue on this specific problem if these suggestions don't help, and we will get things working with you.

[rgknox]

@huitang-earth : Oh, item 3, good point, we should get a C4 plant into the test set. Having that in there would have caught the bug you first pointed out! Thanks!

[rgknox]

@huitang-earth , added c4 plant to the default in PR #347

[jenniferholm]

@rgknox - I have some time to help with allometric parameterization, and would love to work with you on sensitivity tests. Do you have a working game plan for this, and could we coordinate?

@mdietze - thanks for posting the PEcAn allometry module, and I'm interested in using that. I should have talked to you and @serbinsh about this last week, but is there an accessible version of PEcAn and FATES that I could work with? I know Shawn is running some simulations, but wondering the current status.

Awhile ago I looked into some basic differences in using different allometric coefficients based on Ter-Mikaelian and Korzukhin 1997, compared to the current FATES (tropical) Saldarriaga default. Of course there is a large spread in the representation of wood biomass and leaf biomass, but at least the FATES default falls in the middle.

https://www.sciencedirect.com/science/article/pii/S0378112797000194

[rgknox]

Thanks @jenniferholm , I will check in with you to coordinate on developing these allometries.

[mdietze]

@jenniferholm Yeah, there are a lot more recent allometry synthesis efforts than Ter-Mikaelian. Even the Jenkins DB that we’re using is a bit out of date (and updating that is on my to-do list)

Give the PEcAn module’s vignette a try and if it’s not obvious ping me — it’s a stand alone module that you can run in R on any machine and the link I sent includes download instructions: https://github.com/PecanProject/pecan/blob/develop/modules/allometry/vignettes/AllomVignette.Rmd

[jenniferholm]

Yes, the Ter-Mikaelian is an old one! I'm also looking into doing a synthesis of the BAAD database, as it is more global and includes more PFTs.

https://esajournals.onlinelibrary.wiley.com/doi/abs/10.1890/14-1889.1

[serbinsh]

@rgknox if you need it, you can run FATES in PEcAn at https://modex.bnl.gov Let me know how you might want to run it as I can assist you and get you rolling.

That said, first you would want to run the allometry module and then pass this info to PEcAn via priors for FATES. That said, I only have the current 2 PFT param file version running as the updated multi-pft has not yet been released. In addition, I will need to make more updates to PEcAn wrappers when that param file is released, at least I anticipate the need for some additional updates.

[rgknox]

thanks @serbinsh . Allometry module refers to the pecan vignettes right? I will check in with you if/when I start looking at this. Do you know if the vignettes assume arbitrary functional forms, or do they assume power functions for the relationships?

[serbinsh]

@rgknox yeah, happy to chat through the runs you want to do to make sure everything you need is there and ready to roll. With the updates to FATES, etc I/we have had to make updates to PEcAn as well to make sure it can support any parameter name/changes etc so depending on the recent changes to FATES I may need to update the PEcAn side as well. But that is no problem if it helps you get what you need done.

Is there a specific recent PR of FATES that would need to be supported in PEcAn for this? I can make sure it works on the web interface.

As for the allometry module, the vignette is here: https://github.com/PecanProject/pecan/blob/develop/modules/allometry/vignettes/AllomVignette.Rmd (@mdietze also posted the link above)

The package is really easy to install vignette and module is easy to run on different PFTs or species. As @mdietze points out you can install easily in R as:

in R run:

library(devtools)
install_github("PecanProject/pecan",subdir="base/logger")
install_github("PecanProject/pecan",subdir="modules/allometry")

If you dont use R regularly you may need to install devtools first as:
install.packages('devtools')

I would recommend running R within R studio.

From the documentation

Module to fit a common power-law allometric model to a mixture of raw data and allometric equations in a Heirarchical Bayes framework with multiple imputation of the allometric data

[jkshuman]

@rgknox I would like to help out with this as well.

[rgknox]

@jkshuman , what types of PFTs were you interested in?
I know your work has investigated cerrado/savannah type ecosystems as well as rainforests. I'm guessing tropical and subtropical grasses would be in there. We don't have any dry-forest or cerrado like woody pfts in the model yet, was that something you were interested in too?

[jkshuman]

@rgknox - sure, I can focus on the cerrado/savannah type ecosystems as well as rainforests. If I had to narrow it down to PFTs: savanna tree, tropical forest tree, tropical grass, subtropical grass. I am re-running my tree/grass simulations with fire, so all this is highly relevant. I will keep you posted about the grass testing in particular.

[jkshuman]

@rgknox, @rosiealice in the parameter file should "dbh_repro_threshold" always be set to default to be the same as "allom_dbh_maxheight"? (I had this set up per discussion with one of you for my current simulations) If they should be the same, so can we set it up to default this way, and then allow overwrite if user defined?

[rgknox]

@jkshuman , my take is that they are separate concepts, yet both related to "maturity". One reason there are two values is becuase the diameter at which a tree hits its maximum height might not be the same as the diameter at which it starts changing its reproductive allocation. The other reason is that for trees that have asymptotic height allometries, there is no dbh at maximum height set (or rather, it is set infinitely high).

I'm also wary of setting these up so they default to the same, and have a user over-ride, because its unclear to me how different machines and compilers or maybe different versions of netcdf interpret no-data flags. But maybe there is consistency in that. Its also a good thing, in my mind, that the user is forced to make a decision about the value without relying on a default.

We could improve by cluster these two next to each other, and specify in their metadata (long-name) that they are may be the same or similar values?

[jkshuman]

@rgknox Thank you for the clarification; this is helpful. Your rationale about not using a default is sound. Clustering them, or putting a detail in the meta-data would be helpful.