SLA profile implemented, weird interaction with canopy trimming #383
Comments
|
I'm trying to think out loud why the oscillations occur. I'm guessing when trimming occurs now, it now has helpful and slightly unhelpful impacts. Its helpful because layers that have lower light-levels are culled, but it is unhelpful because it is removing layers that are cheap to make, and thus the mean per-unit cost of cohort total leaf area slighly bumps up. Do I have it right? |
|
Hi Ryan, Thanks for asking! We've looked into a few things that could be driving the oscillations but still have some questions about what is causing them. A few contributing factors that could be at play:
To check this, we looked at leaf area per tree for all size classes. We found that in the sla profile simulation (red lines below), larger size classes (e.g. classes 19-26) have LAI that oscillates on a similar time scale (frequency ~15 years) as the overall LAI. This is markedly different from the control simulation (blue lines). At the other size classes (e.g. classes 5-6), the variability in LAI looks similar between the control (blue) and the sla profile case (red). (The yellow line represents the simulation with sla profile and trim increment decreased from 0.03 to 0.01.) Why these oscillations occur on these longer time scales in the large size classes, and whether they could be contributing enough to drive the oscillations in overall LAI, are still open questions. The oscillations do seem to correlate with canopy trim values (see point #2 below).
If we, look at more years of the sla profile simulation (red) below, we see the oscillation on the ~15yr timescale continues in the large size classes:
Again, why these longer-term oscillations appear in canopy trim in large size classes is still an open question.
If there are other ideas, or areas we should look into further, please let us know. |
|
Thanks Marlies. This is kind of interesting and annoying in equal
measure. I wonder if there's any way of removing the iterative system from
trimming. I put in the memory /time lag idea to stop LAI fluctuating too
much between years, but maybe we could just decide that 'trimming' is set
to a value that gives the exact amount of LAI to fill the last leaf layer
in postive carbon balance (for the last year).
The problem with that would be an inability to respond to better/worse
conditions in the current year (but we already sort-of have that).
I think that maybe the oscillations are an inevitable feature of the
trimming x SLA profile for the reasons you describe, and it's tempting to
say that they could be tuned out with a lower increment, but that would
make the leaves even less responsive to change.
I guess I'm saying that the way trimming works is not the only way it could
work. It's primary function is to avoid trees respiring to death in
sub-optimal conditions for their given allometry. Really, if we had correct
allometry for all grid cells we shouldn't need it, so your suggesting of
modifying the leaf allocation for this site is probably the correct one.
I'll think some more about alternative non-oscillating means of doing this.
Thanks again for doing all these simulations and illuminating this
situation so clearly!
…On Wed, May 16, 2018, 2:54 PM kovenock ***@***.***> wrote:
Hi Ryan, Thanks for asking! We've looked into a few things that could be
driving the oscillations but still have some questions about what is
causing them. A few contributing factors that could be at play:
1. The sla profile makes leaves at the bottom of the canopy, where
trimming occurs, cheaper in terms of carbon and thus more sensitive to
changes in leaf carbon. When trimming goes into effect, the canopy trim
value (a fraction) is applied to the leaf carbon so that carbon allocated
to leaves decreases (or increases). Because the sla profile makes leaf area
cheaper in terms of carbon, more leaves are removed (or added) for a given
change in leaf carbon. Thus, trimming the same amount of carbon is expected
to cause larger swings in LAI in the sla profile case than in the control
case.
To check this, we looked at leaf area per tree for all size classes. We
found that in the sla profile simulation (red lines below), larger size
classes (e.g. classes 19-26) have LAI that oscillates on a similar time
scale (frequency ~15 years) as the overall LAI. This is markedly different
from the control simulation (blue lines). At the other size classes (e.g.
classes 5-6), the variability in LAI looks similar between the control
(blue) and the sla profile case (red). (The yellow line represents the
simulation with sla profile and trim increment decreased from 0.03 to 0.01.)
Why these oscillations occur on these longer time scales in the large size
classes, and whether they could be contributing enough to drive the
oscillations in overall LAI, are still open questions. The oscillations do
seem to correlate with canopy trim values (see point #2
<#2> below).
[image: screen shot 2018-05-16 at 8 50 13 am]
<https://user-images.githubusercontent.com/19861621/40143178-9ac53932-590f-11e8-9ede-64d80845e876.png>
[image: screen shot 2018-05-16 at 1 49 23 pm]
<https://user-images.githubusercontent.com/19861621/40143330-fe3e0098-590f-11e8-8dbf-24b5934c8fcb.png>
If we, look at more years of the sla profile simulation (red) below, we
see the oscillation on the ~15yr timescale continues in the large size
classes:
[image: screen shot 2018-05-16 at 1 37 29 pm]
<https://user-images.githubusercontent.com/19861621/40143398-34ea9ea8-5910-11e8-8ca7-1e4c69ea6c4f.png>
1. Canopy trim values (the fraction that is used to scale up or down
leaf carbon in the trimming function) follow a similar pattern to that of
LAI per tree. For most size classes, the sla profile has a similar pattern
of variability as the control but lower mean canopy trim value. However,
the larger size classes show longer-term oscillations in canopy trim.
Again, why these longer-term oscillations appear in canopy trim in large
size classes is still an open question.
[image: screen shot 2018-05-16 at 8 48 30 am]
<https://user-images.githubusercontent.com/19861621/40143261-d63e73d4-590f-11e8-830f-5f1a51aeec19.png>
[image: screen shot 2018-05-16 at 8 49 45 am]
<https://user-images.githubusercontent.com/19861621/40143267-d914ebe2-590f-11e8-8dc7-8372fa0d9485.png>
1. Population dynamics could be driving the oscillations in the sla
profile case. Charlie pointed that the timescale associated with the
oscillations is similar to that for patch fusion.
If there are other ideas, or areas we should look into further, please let
us know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#383 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQzI0hrZqGWco9k1JTYYh9yYt6brFks5tzJIRgaJpZM4UAW17>
.
|
|
I guess the issue with the non-iterative way of optimizing LAI is that we'd have to calculate the carbon balance per layer of leaf even for layers where there aren't currently leaves, which would entail a bit of a reshuffling of how the radiative transfer all works... |
|
Hmm. Yes that's true. Also you in principle only end up with LAIs of exact
multiples of dinc.
…On Wed, May 16, 2018, 4:55 PM Charlie Koven ***@***.***> wrote:
I guess the issue with the non-iterative way of optimizing LAI is that
we'd have to calculate the carbon balance per layer of leaf even for layers
where there aren't currently leaves, which would entail a bit of a
reshuffling of how the radiative transfer all works...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#383 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQzKdFtX_IP3VKRu4AvhKNm4cZEFOks5tzK5vgaJpZM4UAW17>
.
|
|
could the oscillating behavior be a function of dinc being too large? I can imagine a scenario where that two could be related. it might be useful to see if the behavior still happens when dinc is smaller, like 0.25? |
|
Quite possibly yes...
…On Wed, May 16, 2018, 5:09 PM Charlie Koven ***@***.***> wrote:
could the oscillating behavior be a function of dinc being too large? I
can imagine a scenario where that two could be related. it might be useful
to see if the behavior still happens when dinc is smaller, like 0.25?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#383 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQ8e-KvAHlQAvRmJfAaQ4d2UOXd7_ks5tzLHCgaJpZM4UAW17>
.
|
|
Thanks for the suggestions everyone! I'll try a simulation with dinc = 0.25 and post the results asap. |
|
I ran the simulation with lower dinc and learned from the output that there was likely an error in the sla profile code. After revisiting the code, I found that I was using an inconsistent sla profile when calculating tree_lai versus when I was calculating the leaf_cost in the trim_canopy subroutine. (I used tree_lai for the overlying leaf area to calculate the sla profile for the tree_lai calculation (following clm), rather than laican as used for fates vcmax and leaf_cost.) We're working on updating the code to fix this and will post new results once they are ready. Another question, are there LAI observations for bci that we would like to benchmark to? Thanks! |
|
Hi Marlies, thanks for sharing these results. Interestingly, I also have just recently been playing around with altering the canopy trimming logic, and also finding some weird results. At the Manaus, ZF2 site. Here are a couple questions for you, and also some suggestions ---
I'm interested in seeing your carbon starvation mortality results, and if I find out any insight with my tests I'll be sure to report it!! |
|
@kovenock The STRI group at BCI have LAI timeseries. I am planning to work with them in the near future to consolidate this data to the BCI testbed. Some of their LAI (as well as lifespan, litterfall, etc) data that has already been published is in fig. 7 of this: https://www.nature.com/articles/s41467-018-03306-9 |
|
@ckoven Thank you for the link to the BCI LAI figure! @jenniferholm I'm happy to share the M3 results for the simulations above, with the caveat that the sla profile simulations might be strange due to the error I mentioned above. (I can send M3 result for these again once we fix the code.) I'll send you an email with the monthly M3 files and the parameter file we used. Please feel free to ask for other information as needed. Briefly, I used a model branch from Charlie called ""merged_parprof_decouplebroot" and we made some parameter changes to his default parameter file called fates_params_baseline1_leafclumping_nomaxsize_newsai.c180308.nc. Some parameter changes we made could matter for you. For example, we set: fates_cushion = 2 We turned trimming off by setting trim_limit = 1. |
@aswann , @ckoven , and I have implemented a sla profile in FATES so that sla grows exponentially with canopy depth as supported by observations (Lloyd et al. 2010). In doing so, we've run into some strange behavior. We would like share these results with the wider community and ask for your feedback on our proposed next steps.
Briefly, we implemented a sla profile by replacing static sla values (same value at all canopy depths) with sla values that exponentially increase with depth in the canopy. These updates were made both to the calculation of LAI and, in the canopy trimming submodule, to the calculation of leaf cost. Both of these routines use 1/sla to represent the carbon cost of building a unit of leaf area. In our implementation, sla growth through the canopy uses the same coefficient as already used in FATES for nitrogen scaling (following Lloyd et al. 2010). Our expectation is that implementing this sla profile allows plants to grow more leaf area overall since leaf area at the bottom of the canopy costs less carbon to build.
We found that implementing this sla profile causes LAI to oscillate on a ~15yr timescale (light red line in plot below). This oscillation goes away when we turn trimming off (purple line at top) or turn trimming down by reducing the trim increment (how much canopy trimming increases each time trimming goes into effect) from 0.03 to 0.01 (light blue line) and 0.001 (dark red line). However, LAI is then sensitive to the trim increment parameter (trim_inc, abbreviated as tinc in plot legend), as shown by the difference between the light blue and dark red lines. For reference, the dark blue line in the plot shows LAI for a control simulation with trimming turned on; the yellow line shows a control simulation with trimming turned off. All simulations were run using a model version prior to recent conductance updates at BCI under 400 ppm CO2.
Given this weird behavior when the sla profile is implemented an trimming is on, we think our plan going forward will be to turn off canopy trimming. To bring LAI in line with observations (reduce from ~6.5 when trimming is off, purple line), our working plan is to alter the leaf biomass allometry so that less biomass is allocated to leaves. We were wondering if other FATES users/developers (e.g. @rosiealice) have thoughts on this?
The text was updated successfully, but these errors were encountered: