Cache Look Up Table

[philippeverley]

For a given set of parameters, the simulation initialization steps hangs for a few seconds for the look up table (LUT further on) calculations. Let's try to cache this step and see if it speeds up the initialization time. It would be convenient for running tests during development.

[sylvainschmitt]

Great! This is something I thought off for a long time but was too lazy to do in rcontroll. If I recall right I think you can even generate it in the CPP compilation, but inflating the resulting compiled object.

[philippeverley]

I thought about it and actually we want to address two needs:

• Speed up development process by eliminating repeated LUTs calculation at every compile/run/test cycle, both locally and in the GA workflow.
• Speed up runtime execution by eliminating initial LUTs calculation at every run.

Here is a proposed approach:

1. cache target: A custom CMake target that runs a C++ program (generate-lut-header.cpp or something equivalent) to compute the LUTs and generate a lut.hpp header with computed values.
2. commit the lut.hpp considering it does not change often
3. update the build target to include lut.hpp

I could skip the commit of lut.hpp (it would still be perfectly efficient for local execution) but then it would add complexity to the caching strategy in the GA to benefit from the LUTs calculation. I've not looked at the void InitialiseLookUpTables() function but at first sight the LUT are fully determined by two hard-coded parameters nbTbins and Taccuracy so it seems unlikely that the lut.hpp will change often.

@IsabelleMarechaux @sylvainschmitt do you confirm that the LUTs do not often change?

[IsabelleMarechaux]

yes !
the only exception is LookUpLAImax (initialise in InitialiseLookUpLAImax which is called at the end of the InitialiseLookUpTables), which depend on the number and idenitity of species provide din the input species file.
Apart for this one, the other should not change, unless we, at some point decide to try applying TROLL in other biomes... but not currently.

[philippeverley]

I think this work on the LUTs is the perfect occasion to bring in some information inside the code documentation.

Let's take the example of the Km(T) Michaelis-Menten constant for CO₂. Current source code says:

LookUp_KmT[i] = 404.0 * exp(((temper - 25.0) / (298 * 0.00831 * (273 + temper))) * 59.36) *
                        (1 + 210 * 1.0 / 248.0 * exp(-(temper - 25.0) / (298 * 0.00831 * (273 + temper)) * 35.94)); // taken from von Caemmerer 2000, as in Domingues et al. 2010, for consistency

And from Domingues et al. 2010 I read that

Km <- Kc_Tleaf*(1+O2/Ko_Tleaf)
Kc_Tleaf <- Kc * exp((Tleaf+273.15-298.15)*delta_Kc/(298.15*8.314*(Tleaf+273.15)))
delta_Kc <- 59356 	# activation energy (kJ mol−1) - Badger & Collatz (1977)
Ko_Tleaf <- Ko * exp((Tleaf+273.15-298.15)*delta_Ko/(298.15*8.314*(Tleaf+273.15)))
Kc <- 40.49 	# Michaelis-Menten constant for CO2 (Pa) - von Caemmerer et al. (1994)
Ko <- 24.8 	# Michaelis-Menten constant for CO2 (kPa)- von Caemmerer et al. (1994)
O2 <- 21 	# Estimated Oxygen concentration at mesophyll - (kPa)
delta_Ko <- 35948 	# activation energy (kJ mol−1) - Badger & Collatz (1977)

It looks similar indeed, but it is not straighforward (at least not for me) to work out how one departs from Domingues equations and arrives at the Km LUT in TROLL.

@IsabelleMarechaux would you be willing to assist me on the topic ? Clarify and comment everything. Would could do it for Km(T) and Gamma(T) LUT and decides whether it is worth carry on to the other tables ?

[sylvainschmitt]

Hello, my two cents on LUT is that we can also check them first against climate input. Indeed in rcontroll I have pushed the number of bins to 600 (VPD=6), which should be higher that what you have : https://github.com/sylvainschmitt/rcontroll/blob/4547e4ac0009251500c49c5d3c2cc3831cdad24d/src/troll_rcpp.cpp#L5849 . The reason behind is that I made simulations with climate change projections and thus higher VPD that resulted in code crash with the previous lower value of nbVPDbins. This results in heavier LUTs and is not needed for most simulations I imagine. So I don't know if you want to precompute large table to avoid extending them, or if you prefer extending them solely in case of needs. However, I think in any case it should deserve a safety to avoid the LUT encountering climate values they were not computed for.

[IsabelleMarechaux]

sure @philippeverley
I won't be able to do that today, but can spend time on this by the end of the week.
best

[philippeverley]

sure @philippeverley I won't be able to do that today, but can spend time on this by the end of the week. best

Thanks Isa, no rush at all. I'll show you what I have in mind, and we can add up some info incrementally, LUT by LUT.

[philippeverley]

Hello, my two cents on LUT is that we can also check them first against climate input. Indeed in rcontroll I have pushed the number of bins to 600 (VPD=6), which should be higher that what you have : https://github.com/sylvainschmitt/rcontroll/blob/4547e4ac0009251500c49c5d3c2cc3831cdad24d/src/troll_rcpp.cpp#L5849 . The reason behind is that I made simulations with climate change projections and thus higher VPD that resulted in code crash with the previous lower value of nbVPDbins. This results in heavier LUTs and is not needed for most simulations I imagine. So I don't know if you want to precompute large table to avoid extending them, or if you prefer extending them solely in case of needs. However, I think in any case it should deserve a safety to avoid the LUT encountering climate values they were not computed for.

Thanks Sylvain ! So far number_of_bins and temperature_precision are hard-coded constants in the code. I do understand that the extent of the LUTs must be compatible with parameters' space of a given configuration.

I aslo pinpoint that what I did so far is not satisfactory because if #WATER is not defined then LUTs Km and Gamma for instance need the iCair = 1/Cair parameters, and I did not included yet mechanism to read the input configuration in the generate-lut-header executable. I first want to understand better and work on the input management before proceeding.

I'm going to create a related issue as a reminder so that in future the LUT generation will check the parameters first and adapt the number of bins 👍