Accounting for boundary layer conductance in fitBB

Issue #44 resolved
Kevin Wolz
created an issue

The "Ca" in all BB-type models considered by fitBB is the [CO2] at the leaf surface. Currently the default column from which fitBB pulls Ca is set to "CO2S", which represents the [CO2] within the LI6400 chamber. Even though, LI6400 chambers are considered "well-mixed" there is technically still a small boundary-layer conductance at the leaf surface that causes the [CO2] at the leaf surface to be different than that in the chamber as a whole. Licor provides columns in the standard LI6400 output files that calculate this boundary layer conductance. The calculation goes as follows: A slope (BLCslope) and intercept term (BLCoffst) scale the chamber/leaf area (Area) to calculated a baseline boundary layer conductance for a give LI6400 head (BLC_1). This baseline conductance is modified by the stomatal ratio of the leaf (StmRat) to calculate the actual boundary layer conductance (BLCond).

In newer versions of LI6400 firmware, the output files (the new files that actually have formulas built into the cells) actually use BLCond to calculate columns of RHsfc (relative humidity at the leaf surface) and C2sfc ([CO2] at the leaf surface). Licor has even taken it a step further to add a nifty column called "AHs/Cs", which is the BallBerry index (although I don't that's particularly useful for fitBB).

I think it is worth considering switching the default column name used by fitBB for Ca to "C2sfc". And actually (contrary to Issue #43), for the BallBerry model, the default column for RH should be "RHsfc". For the other models that use VPD instead of RH, I'm not sure how this boundary layer issue would affect things - you would know better on that.

All that said, many older LI6400 output files may not have these two new columns (C2sfc, RHsfc), so setting them as defaults may throw more errors than anything. Furthermore, accurate calculation of these columns completely depends on the LI6400 user setting the stomatal ratio of the leaves they're working with (almost never happens when measurements are taking place - and users may not even know what the stomatal ratio is). For the latter point, the new LI6400 versions at least allow you to change this value in the XLSX output file and then the formulas in the spreadsheet will automatically re-calculate everything based on that.

So, I'm not sure if it makes more sense to

1) Use "C2sfc" and "RHsfc" as the default columns (if everyone already has these columns anyway), or

2) Have fitBB calculate the surface values itself using the boundary layer conductance columns instead (these columns are always present I think), or

3) Directly code the boundary layer conductance formulas into fitBB, with new input variables to fitBB being added as (1) the chamber/leaf area and (2) the stomatal ratio.

This modification is obviously not 100% necessary to get a good BB fit. However, as a community, we need to decide whether g1 in BallBerry fits represents a fit with ambient [CO2] or leaf surface [CO2], and then we need to fit the model consistently. It seems to me that we have all been defining Ca as leaf surface [CO2], so I think fitBB would do best to fit the data accordingly.

This enhancement probably also has implications for how Photosyn deals with boundary layer conductance (need to sum boundary layer and stomatal conductance to calculate Ci), but I'll save that for another time after we've hashed some things out here and after I've played with Photosyn more thoroughly.

Comments (4)

  1. Remko Duursma repo owner

    Thanks for the detailed report. You make a good point here, it might make some difference when considering the boundary layer conductance. Before any action is taken, though, it would be worth seeing how much difference it actually makes. This may be a good topic for a short vignette.

    My short response to all of this is that a) it calls for some better documentation for the user, to consider whether to account for boundary layer conductance or not, b) changing default column names is inadvisable for two reasons (breaking old code; new users may not have these columns), and c) I doubt it makes much difference in almost all cases, since the boundary layer conductance is of course very high in a cuvette. But I am not 100% certain on point c), so that could be developed further.

    In terms of your comment as a community, we need to decide whether g1 in BallBerry fits represents a fit with ambient [CO2] or leaf surface [CO2] - you are right, there is certainly a mixture of those (we always use CO2, since that is what models will always have, but won't have leaf surface CO2 in all cases, reminding ourselves that we do this so that models can use values of g1!). But again the question is how much difference does it make.

    Finally This enhancement probably also has implications for how Photosyn deals with boundary layer conductance - the boundary layer effect for water vapour (affecting energy balance and leaf temperature) is a far more important issue, and is dealt with in PhotosynEB. However I should take a look at photosynthesis effects.

  2. Kevin Wolz reporter

    Just one quick follow up regarding the magnitude of the effect of boundary layer conductance. Some quick math...

    Typical stomatal conductance to water we have measured: 0.2

    Boundary layer conductance to water of the most common cuvette we use: 4.6 (fixed, as calculated by Licor)

    With just the stomatal conductance, you have 0.2/1.6 = 0.125 for total conductance of CO2 from ambient to inside the leaf.

    Summing (the inverses) stomatal and boundary layer conductances, you get: 1 / (1.6/0.2 + 1.37/4.6) = 0.121

    This is a ~3% decrease in perceived conductance.

    For higher stomatal conductance (which we've observed up to 0.8 in powerhouse species such as soybean), the perceived decrease approaches 13%:

    0.8 / 1.6 = 0.5

    versus

    1 / (1.6/0.8 + 1.37/4.6) = 0.435

    The inverse summing formula used above is what is used by Licor, although I'm currently blanking on where the factor of 1.37 comes from and why this isn't also 1.6. I'll have to check the manual.

  3. Log in to comment