Branch turnover

[rosiealice]

Summary of Issue:

There is a strong science case for adding in wood turnover. This was never a feature of ED, on account of allometric complications. Specifically, if there is wood turnover but no production, the trees can get 'off allometry' and parameterizations would be needed to re-instate allometric balance post drought/winter etc.

Charlie suggests that we can get around the 'off allometry' problem by only allowing/requiring turnover when there is actual woody biomass growth. Thus turnover is a tax on construction. Implementation would require:

1) sapwood turnover parameter (this might already exist?) 2) population of existing woody litter classes with stem turnover rates 3) reduction of woody growth derivative to account for turnover tax 4) confirmation that all of the above does not break carbon balance and that it has the desired impact on litter pools.

Expected behavior and actual behavior:

Steps to reproduce the problem (should include create_newcase or create_test command along with any user_nl or xml changes):

What is the changeset ID of the code, and the machine you are using:

have you modified the code? If so, it must be committed and available for testing:

Screen output or output files showing the error message and context:

[mdietze]

Not sure I follow the "turnover is a tax on construction" idea. Phenologically, turnover occurs at different times of the year than growth and they respond to stress differently. For example, a drought that causes a reduction in growth probably also causes an increase in branch turnover (dieback) rather than a reduction, which is what would happen if turnover is treated las a 'tax' similar to growth respiration. Even without stress, in temperate systems you'll get growth in the summer and branchfall in the winter (snow & ice loading), again with no real coupling in their magnitudes.

Don't know if you want to go this far, but there's also literature linking understory mortality, biomass turnover, and resprouting to canopy branchfall. I have good data for this from some of my own temperate sites and I know it's been looked at in some of the tropical sites (e.g. BCI, La Selva).

[ckoven]

@mdietze agreed in principle that what you are saying is of course correct. what i was proposing is that perhaps a better assumption than the current one—in which we assert that all wood is in the trunk and lasts as long as the tree—would be one where we try to account for branchfall in the long-term growth trajectory but make a sort of equilibrium branchfall assumption in which we set branchfall as a tax on growth. since, unlike the leaf case, the seasonal cycle of branch mass is not what we are thinking is important, this lack of an asynchrony between growth and branchfall may be a useful interim step until we can have actual branch responses to disturbance, but without the headache of including off-allometry logic.

I guess the first step on this is to track down datasets of branchfall rates. Spoke with Helene Muller-Landau at the meeting just now and she says that (a) she has data on this and that (b) thinking of it as a constant fraction of woody production is probably ok as a start. Will follow up with her on figuring out what the tax ought to be.

[mdietze]

I guess I don't see what the headaches of off-allometry growth are. We never put branchfall into ED2 explicitly, but I did put in the capacity to reduce AGB without affecting BGB as part of some of the biofuel & management work we did, as well as to support the capacity to generate resprouting. There's definitely a couple gotchas to watch out for, but I didn't find it a headache. If I recall I ended up splitting sapwood and bdead into above and belowground parts explicitly and then just set the off-allometry allocation to each pool to be proportional to how far off allometry they were. So, for example, after a cut a stem would allocate 100% of new growth to aboveground, while turnover would 'prune' the roots. The 'gotcha' is to not let DBH decline in response to an AGB decline, which does't make sense ecologically and would put you on a new allometry

I agree that dynamic branchfall involves a lot more work, but constant branchfall seems more defensible ecologically than coupling it to growth.

[rosiealice]

So, the resprouting point is a good one, since we are probably going to have to grapple with that for fire and/or resprouting at some point in at least the medium-term...

We seem to thus have the option of more or less extensive code modifications which would be more and less useful, respectively. Maybe 'production tax branch turnover' and 'off allometry capacity' could become different tasks, just to keep everyone sane?

Thanks for weighing in on this Mike! Good to have your perspective :)

On Sep 22, 2016 4:52 PM, "Michael Dietze" notifications@github.com wrote:

I guess I don't see what the headaches of off-allometry growth are. We never put branchfall into ED2 explicitly, but I did put in the capacity to reduce AGB without affecting BGB as part of some of the biofuel & management work we did, as well as to support the capacity to generate resprouting. There's definitely a couple gotchas to watch out for, but I didn't find it a headache. If I recall I ended up splitting sapwood and bdead into above and belowground parts explicitly and then just set the off-allometry allocation to each pool to be proportional to how far off allometry they were. So, for example, after a cut a stem would allocate 100% of new growth to aboveground, while turnover would 'prune' the roots. The 'gotcha' is to not let DBH decline in response to an AGB decline, which does't make sense ecologically and would put you on a new allometry

I agree that dynamic branchfall involves a lot more work, but constant branchfall seems more defensible ecologically than coupling it to growth.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/NGEET/ed-clm/issues/126#issuecomment-249024371, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ8BVmMTGR7yaZgyGNGBl31qcrBNKks5qsup3gaJpZM4KEOBK .

[ckoven]

i guess i don't see why branchfall ought to scale with biomass instead of growth rates. to me, a tree ought to drop a branch when it is shaded, so that a fast-growing tree ought to shed branches faster than a slow-growing tree because it is shading its lower branches at a faster rate? if you do it as a constant fraction of biomass, then you'd end up with fundamentally differently-shaped fast-growing versus slow-growing trees, which I don't feel like is what you see in the real world? anyway i'm not saying that a "growth tax" is definitely the right way of doing it but not sure that a "maintenance tax" is better...

[mdietze]

Good points. I guess I've been focusing on branchfall as a primarily driven by random events (approximately constant?) and mild disturbances (wind, ice). I wasn't thinking about self pruning. So, like respiration, the right answer is probably that both are important and that we need to look at actual data to see if one is significantly dominant over the other to ignore the other term.

I like Rosie's idea of splitting this into two tasks, and now see implementing Charlie's approach as half the solution rather than an interim solution. Just need to remember to recalibrate when the other half is added, because the self pruning rate will have to be set too high in the mean time in order to get the right total woody debris.

[rgknox]

Here is that flow chart I made a while ago that shows the order of operations for carbon allocation balancing as it now stands in FATES. As you can see we don't use a target system. Net daily carbon gain is used first to fill some leaf and fine-root turnover (at any cost, even if daily net gain becomes negative). Then storage is filled and also storage is potentially drawn from to bring net carbon gain back to zero.

It seems like a potentially useful method of including branch turnover is to move to a system that uses target biomass pools, and tries to push the different pools towards their targets given the available net daily carbon chunk.

[tompowell9]

Hi Ryan,

This is a cool graphic--very helpful for visualizing how C distribution works in FATES. Your last point about target for biomass pools makes sense to me. Correct me if I am wrong, but this sounds like our notion of being "on or off allometery". I have a few questions and comments:

1. Where would branch turnover be inserted in this graphic?
2. Would branch turnover be active from the beginning or would it turn on after the plant reaches a certain height?
3. Is there a way to bring in branch turnover without adding too many more parameters to an already over-parameterized model?
4. It seems to me that we want to ramp up branch turnover in a very significant way as the plant approaches the top of the canopy. Doing this will help to constrain height growth in a realistic way without just capping height as we do in ED. And, it may also allow for a few "emergents" to comprise a small fraction of the canopy. I am thinking that the branch turnover could become very large when the trees reach 35 m where the plant can only grow in height by about 1m per 20 years. Therefore, to get from 35 m to 50 m, the plant would need to be alive for an additional 300 years. In the real forest, the 50 m tall trees are > than 300 years old.
5. In the graphic, it strikes me as strange to have C be directly allocated to the dead pool from C4. It seems to me that the magenta line should be going from the "alive" pool to the "dead" pool; not from the C4 pool to the "dead" pool. My point may be moot in the current incarnation of the model where either way, the accounting results in the same answer. But, when the hydrodynamics are introduced, the alive pool will also be the conductive-wood pool and this pool needs to be able to transfer C to the dead pool, and go off the dead:alive allometry, in order to account for cavitation and subsequent xylem repair. Therefore, it may behoove you to channel this carbon through the alive pool now, otherwise you will need to make some sort of patch in the future when the hydrodynamics come in.

Cheers, Tom

On Tue, Sep 27, 2016 at 9:00 AM, Ryan Knox notifications@github.com wrote:

Here is that flow chart I made a while ago that shows the order of operations for carbon allocation balancing as it now stands in FATES. As you can see we don't use a target system. Net daily carbon gain is used first to fill some leaf and fine-root turnover (at any cost, even if daily net gain becomes negative). Then storage is filled and also storage is potentially drawn from to bring net carbon gain back to zero.

[image: npp flux - actual] https://cloud.githubusercontent.com/assets/5891980/18881468/39d42e94-8490-11e6-9998-20ea885270cb.png

It seems like a potentially useful method of including branch turnover is to move to a system that uses target biomass pools, and tries to push the different pools towards their targets given the available net daily carbon chunk.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/ed-clm/issues/126#issuecomment-249910987, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnK6Ombpu9r8ooOheu7CO2zxVxDVxjUks5quT2WgaJpZM4KEOBK .

[rgknox]

BTW, I did not want to over-complicate things for the near term. Hope I didn't side track us. I think the idea to just add a growth tax is an excellent near-term solution to incorporate the carbon losses to branch flux. Responding to Tom: 1) I think if we had targets, the graphic would just be so completely different, instead of being a sequential reduction of the daily carbon nugget, it would be more of the pool being carved up at once and distributed to each pool simultaneously.

[ckoven]

@tompowell9 and all, I think that one thing to keep in mind is that we've been talking for a while about revamping the whole allocation scheme from what is currently in @rgknox's graphic to something where each pool has a target biomass defined as diagnostic by allometric models off of a prognostic dbh and then also a separate prognostic pool that reflects what the tree actually has in terms of resources. there are several reasons to do that, including (1) it is probably required for nutrient stoichiometry; (2) it allows flexibility in representing the kind of disturbance effects that @mdietze referred to earlier; (3) it can hopefully avoid the kind of ambiguity we've run into in big-leaf CLM but also are present to a lesser degree in FATES about the source for maintenance respiration, etc etc..

this is a longer-term task and i think maps out into the kind of short-term implementation of a growth tax versus a longer-term addition of off-allometry logic as described by @rosiealice.

oops looks like @rgknox just wrote the same thing i was writing...

[ckoven]

This is a thing now, as of the new allocation scheme. closing.