LM3-PPA with P-model: unrealistic GPP

[stineb]

I just pushed commit 3de29b after having had another look at the light distribution issue we had. It compiles and runs and I thought it's doing it correctly now. However, it looks a bit unreasonable and needs checking.

I split the code in gpp_lm3ppa.mod.f90 up into first calculating light absorption by each cohort and summing over total light absorption by layer, and then in a second loop, using these values to calculate GPP.

I tested by running analysis/example.Rmd but outputs for GPP (plotted at the bottom) look odd. Should compare to the "gs_leuning" setup and make sure simulated values are in the same ballpark, without excessive variations between years. From a first glance, this is not the case. Needs resolving...

[wengensheng]

Beni, Where can I find the plots? Can you send me a copy by email?

Best, Ensheng

On Mon, Nov 15, 2021 at 9:24 AM Benjamin Stocker @.***> wrote:

I just pushed commit 3de29b after having had another look at the light distribution issue we had. It compiles and runs and I thought it's doing it correctly now. However, it looks a bit unreasonable and needs checking.

I split the code in gpp_lm3ppa.mod.f90 up into first calculating light absorption by each cohort and summing over total light absorption by layer, and then in a second loop, using these values to calculate GPP.

I tested by running analysis/example.Rmd but outputs for GPP (plotted at the bottom) look odd. Should compare to the "gs_leuning" setup and make sure simulated values are in the same ballpark, without excessive variations between years. From a first glance, this is not the case. Needs resolving...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/computationales/rsofun/issues/49, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWR5WUQFN6XLFDA4OOSD2LUMEJ3FANCNFSM5IB2ETEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[khufkens]

@stineb I think this line: https://github.com/computationales/rsofun/blob/7a20f59061776849b238a904079922d08754a0cd/src/gpp_lm3ppa.mod.f90#L349

should read:

myrd = fapar_tree(i) out_pmodel%vcmax25 params_gpp%rd_to_vcmax * calc_ftemp_inst_rd( forcing%Tair - kTkelvin )

as otherwise not defined anywhere

Values are a factor 2x off it seems, using my vignette here: https://bluegreen-labs.github.io/rsofun/articles/lm3ppa_use.html

but this uses different driver data than the example (missing the Rmd in the analysis folder it seems).

[khufkens]

The above issue seems to fix things (spurious deletion @stineb?)

https://github.com/computationales/rsofun/commit/6bb366d5209f890147ede5a770c0ab5f52e4b889

Running the example with a properly formed site_info variable results in the below. On average p-model and gs_leuning are similar, but there is a lot of year to year variability in the p-model implementation. Driver data or settings are key here, and I'll double check this. The vignette shows different behaviour, despite the almost equivalent driver dataset (slight changes in settings).

This is running this script: https://github.com/computationales/rsofun/blob/master/analysis/example_lm3ppa.R

gs_leuning

p-model

[wengensheng]

gs_leuning looks good to me!

On Mon, Nov 15, 2021 at 11:28 AM Koen Hufkens @.***> wrote:

The above issue seems to fix things (spurious deletion @stineb https://github.com/stineb?)

6bb366d https://github.com/computationales/rsofun/commit/6bb366d5209f890147ede5a770c0ab5f52e4b889

Running the example with a properly formed site_info variable results in the below. On average p-model and gs_leuning are similar, but there is a lot of year to year variability in the p-model implementation. Driver data or settings are key here, and I'll double check this. The vignette shows different behaviour, despite the almost equivalent driver dataset (slight changes in settings). gs_leuning

[image: gs_leuning] https://user-images.githubusercontent.com/1354258/141817670-c4714b9f-e8f2-4cdd-9558-abcec867660b.png p-model

[image: pmodel] https://user-images.githubusercontent.com/1354258/141817697-7d921100-50be-4cfe-8be2-c6075304e0f9.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/computationales/rsofun/issues/49#issuecomment-969083880, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWR5WXSWVB35IR3IH746VTUMEYKXANCNFSM5IB2ETEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[stineb]

I agree. The large variation in GPP using the P-model setup still looks odd. I am just seeing that when running vignettes/lm3ppa_use.Rmd, it looks reasonable. Why is that? Is it because the forcing is messed up when running analysis/example_lm3ppa.Rmd?

@wengensheng, thanks for chiming in. As you might have figured, we're implementing the P-model into LM3-PPA and were trying to make sure that the light absorption is correctly implemented, i.e., units of all the variables are correct and energy is conserved (i.e., incident radiation onto layer N is attenuated by absorption by layer N-1). The respective code is here. In the LM3-PPA-P-model setup, we're running the "fast" loop only at daily (not hourly/half-hourly) resolution.

[khufkens]

Script to generate the data in the package is here:

https://github.com/computationales/rsofun/blob/master/analysis/generate_data.R

I did refactor some of it because I was looking at the units used and if simple averages were correct (especially for precipitation - wasn't sure if those were rates of hourly totals).

[khufkens]

@stineb

Given inconsistencies between in package data and the one generated through various markdown files I've consolidated everything in a test suite.

Changes made to the driver data should be done so in the data-raw/generate_data.R file, which updates the internal package data as well.

To run a test on changes to either the the package, the data script, or the vignette to test a run you call from the command line in the project directory either:

# when  you don't want to display the vignette after compilation
sh analysis/test_suite.sh

# when you DO want to display the vignette after compilation
sh analysis/test_suite.sh true

Any errors during the various stages will be shown on the command line as per usual, but this saves calling 2 / 3 scripts per try etc.

[stineb]

@wengensheng @khufkens Corrected P-model implementation in LM3-PPA with commit ce15244.

Please note also changes relevant to gs_leuning photosynthesis setup:

• light extinction factor now set to 0.5
• different approach to calculating light levels per canopy layer.

In particular, the following code:

    ! Use constant light extinction coefficient
    kappa = 0.5

    ! Sum leaf area over cohorts in each crown layer -> LAIlayer(layer)
    LAIlayer(:) = 0.0
    fapar_layer(:) = 0.0
    do i = 1, vegn%n_cohorts
      cc => vegn%cohorts(i)
      layer = Max(1, Min(cc%layer, nlayers_max))
      ! LAIlayer(layer) = LAIlayer(layer) + cc%leafarea * cc%nindivs / (1.0 - f_gap)   ! not used anymore
      fapar_tree(i) = 1.0 - exp(-kappa * cc%leafarea / cc%crownarea)   ! at individual-level: cc%leafarea represents leaf area index within the crown
      fapar_layer(layer) = fapar_layer(layer) + fapar_tree(i) * cc%crownarea * cc%nindivs
    enddo

    ! Get light received at each crown layer as a fraction of top-of-canopy -> f_light(layer) 
    f_light(:) = 0.0
    f_light(1) = 1.0
    do i = 2, nlayers_max
      ! f_light(i) = f_light(i-1) * (exp(-kappa * LAIlayer(i-1)) + f_gap)                     ! originally in LM3-PPA
      ! f_light(i) = f_light(i-1) * ((1.0 - f_gap) * exp(-kappa * LAIlayer(i-1)) + f_gap)     ! corrected version, corresponding to original LM3-PPA approach
      f_light(i) = f_light(i-1) * (1.0 - fapar_layer(i-1))                                    ! new standard version, conserving energy
    enddo

[wengensheng]

Thanks for letting me know. Actually, the calculation of light extinction coefficient was over-simplified. It should be a function of light zenith angle.

Ensheng

On Mon, Nov 22, 2021 at 10:44 AM Benjamin Stocker @.***> wrote:

@wengensheng https://github.com/wengensheng @khufkens https://github.com/khufkens Corrected P-model implementation in LM3-PPA with commit ce15244 https://github.com/computationales/rsofun/commit/ce15244b8c4ddf97874f63d1b24345a18854b83c .

Please note also changes relevant to gs_leuning photosynthesis setup:

• light extinction factor now set to 0.5
• different approach to calculating light levels per canopy layer.

In particular, the following code:

! Use constant light extinction coefficient
kappa = 0.5

! Sum leaf area over cohorts in each crown layer -> LAIlayer(layer)
LAIlayer(:) = 0.0
fapar_layer(:) = 0.0
do i = 1, vegn%n_cohorts
  cc => vegn%cohorts(i)
  layer = Max(1, Min(cc%layer, nlayers_max))
  ! LAIlayer(layer) = LAIlayer(layer) + cc%leafarea * cc%nindivs / (1.0 - f_gap)   ! not used anymore
  fapar_tree(i) = 1.0 - exp(-kappa * cc%leafarea / cc%crownarea)   ! at individual-level: cc%leafarea represents leaf area index within the crown
  fapar_layer(layer) = fapar_layer(layer) + fapar_tree(i) * cc%crownarea * cc%nindivs
enddo

! Get light received at each crown layer as a fraction of top-of-canopy -> f_light(layer)
f_light(:) = 0.0
f_light(1) = 1.0
do i = 2, nlayers_max
  ! f_light(i) = f_light(i-1) * (exp(-kappa * LAIlayer(i-1)) + f_gap)                     ! originally in LM3-PPA
  ! f_light(i) = f_light(i-1) * ((1.0 - f_gap) * exp(-kappa * LAIlayer(i-1)) + f_gap)     ! corrected version, corresponding to original LM3-PPA approach
  f_light(i) = f_light(i-1) * (1.0 - fapar_layer(i-1))                                    ! new standard version, conserving energy
enddo

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/computationales/rsofun/issues/49#issuecomment-975657670, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWR5WW6RV2KEBQHBSSC6L3UNJQPRANCNFSM5IB2ETEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[khufkens]

@stineb

Do the new results look ok to you. Running the vignette I get this on my fork, where values are not really equivalent but at least not too much of the mark.

https://bluegreen-labs.github.io/rsofun/articles/lm3ppa_use.html

[stineb]

Yes, looks ok. Values are not necessarily similar since a very different photosynthesis routine is used. The model will have to be calibrated separately for each setup. It will be good to demonstrate model calibration to the same data for the two setups.

[khufkens]

Taking care of these little things. There are some constraints on this so it will be in sofuncalval rather than the package.

On Tue, 23 Nov 2021 at 13:13, Benjamin Stocker @.***> wrote:

Yes, looks ok. Values are not necessarily similar since a very different photosynthesis routine is used. The model will have to be calibrated separately for each setup. It will be good to demonstrate model calibration to the same data for the two setups.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/computationales/rsofun/issues/49#issuecomment-976452678, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKKUEWZGTRWYIFALWZFMA3UNOANHANCNFSM5IB2ETEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Koen Hufkens, Ph.D.

ETH Zurich Computational Ecosystem Science

Ghent University Computational & Applied Vegetation Ecology Lab

Congo basin eco-climatological data recovery and valorisation (COBECORE) project lead (www.cobecore.org)

@koen_hufkens co-founder of bluegreenlabs.org