Negative leaf_NPP ?

[jenniferholm]

Summary of Issue:

When running FATES in a northern CA site for 200 years, using either needleleaf evergreen tree or broadleaf evergreen temperate tree PFT, there is a cyclical occurrence of leaf_npp becoming negative (for the period of a couple months out of the year) which then makes total npp become negative. I wanted to create this issue for a couple reasons; 1) to start a discussion on if it seems plausible for NPP, specifically leaf NPP, to be negative? Probably yes, due to high respiration, resorption and pulling from storage pools. 2) to highlight and document as a potential issue to look into about the carbon allocation scheme in general in FATES.

I haven't fully investigated why leaf_npp becomes negative but it seems related to the maintenance demand becoming large, and larger than the available NPP. Question to the group - should we look into the instances when maintenance demand becomes larger than the available NPP (therefore carbon loss, no allocation of carbon to growth) in FATES, or is this a non-issue and correct model behavior? Specifically FATES might be incorrectly "putting" that loss of carbon into a wrong carbon pool or accounting the carbon balance and carbon allocation in a funny way.

In addition all the other NPP pools are positive (npp_dead, npp_alive, npp_storage, npp_seed), but only npp_leaf is the contributor to the negative total NPP.

There may be some areas in the carbon allocation scheme and algorithms with regards to leaf_md, root_md, and npp_leaf that need to be evaluated. Below is some of the code that calculates npp_leaf.

Inside EDPhysiologyMod.F90 =

currentCohort%npp_leaf = min(currentCohort%nppcurrentCohort%leaf_md/currentCohort%md, & currentCohort%leaf_mdEDecophyscon%leaf_stor_priority(currentCohort%pft))

Expected behavior and actual behavior:

A negative NPP can realistically occur if respiration overpowers carbon, however the current scheme and procedure of how negative NPP might need to be re-evaluated in the FATES carbon allocation and carbon balance scheme, because a negative leaf pool might not be appropriate.

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:

[ckoven]

@jenniferholm this seems pretty unsurprising to me. in principle npp should be negative for part of the year throughout the mid to high latitudes, especially for trees that are evergreen and so keep leaf respiration high during nonproductive seasons. thinking through some of the carbon balance issues for mediterranean ecosystems, it may be that the phasing of phenology, allocation, or respiration may need more thought in that specific case, but otherwise i'd expect this sort of thing to happen.

[rosiealice]

Hi Jennifer,

So, it should be set up to handle negative NPP in general, mostly by extracting that C from the storage pool - obviously, that's a thing that's normal in winter/droughts. The question that came up for evergreen vegetation is whether to a) cease leaf turnover or b) extract C from the store pool, so the allocation scheme is set up to allow for prioritization wherever the 'leaf_stor_priority' shows up.

Having said that, I don't know if the tissue-specific NPP diagnostics are set up to figure this out. I guess that in principle, if the leaves were using up carbon from their own stores, their mass would decline, and if you were very pedantic about measuring pools & fluxes, etc. that should show up? Of course, no-one would ever do that because leaf harvests are destructive, but I don't think a negative productivity should be actually impossible?

On 21 December 2016 at 17:52, Jennifer Holm notifications@github.com wrote:

Summary of Issue:

When running FATES in a northern CA site for 200 years, using either needleleaf evergreen tree or broadleaf evergreen temperate tree PFT, there is a cyclical occurrence of leaf_npp becoming negative (for the period of a couple months out of the year) which then makes total npp become negative. I wanted to create this issue for a couple reasons; 1) to start a discussion on if it seems plausible for NPP, specifically leaf NPP, to be negative? Probably yes, due to high respiration, resorption and pulling from storage pools. 2) to highlight and document as a potential issue to look into about the carbon allocation scheme in general in FATES.

I haven't fully investigated why leaf_npp becomes negative but it seems related to the maintenance demand becoming large, and larger than the available NPP. Question to the group - should we look into the instances when maintenance demand becomes larger than the available NPP (therefore carbon loss, no allocation of carbon to growth) in FATES, or is this a non-issue and correct model behavior? Specifically FATES might be incorrectly "putting" that loss of carbon into a wrong carbon pool or accounting the carbon balance and carbon allocation in a funny way.

In addition all the other NPP pools are positive (npp_dead, npp_alive, npp_storage, npp_seed), but only npp_leaf is the contributor to the negative total NPP.

There may be some areas in the carbon allocation scheme and algorithms with regards to leaf_md, root_md, and npp_leaf that need to be evaluated. Below is some of the code that calculates npp_leaf.

Inside EDPhysiologyMod.F90 =

currentCohort%npp_leaf = min(currentCohort%npp currentCohort%leaf_md/currentCohort%md, & currentCohort%leaf_mdEDecophys con%leaf_stor_priority(currentCohort%pft)) Expected behavior and actual behavior:

A negative NPP can realistically occur if respiration overpowers carbon, however the current scheme and procedure of how negative NPP might need to be re-evaluated in the FATES carbon allocation and carbon balance scheme, because a negative leaf pool might not be appropriate. 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:

— 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/164, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ4gnj-vSZ6RilJCJu59tIizncPG4ks5rKcnXgaJpZM4LTiCg .

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706

http://www.cgd.ucar.edu/staff/rfisher/

[jenniferholm]

Hi all,

Thanks for the comments. I don't think I was completely clear in my original posting. I also agree that a negative NPP is valid, and something that we should expect (especially in higher latitudes for evergreen trees in winter, like Charlie pointed out). So I thought it was kind of neat to confirm that negative NPP occurred in mid latitudes in FATES.

(Not a high priority) but I just wanted to make sure that the algorithm design in the model was set up appropriately for carbon balance and high respiration/non-reproductive seasons. As Rosie mentioned the negative NPP should extract C from the store pool, and I think we should look into this and make sure this is in fact the case. Because from initial investigation it looks like the scheme is not extracting from storage pool, but instead for leaf pool. (but if that is the correct order/path, then this can be a mute point).

Jennifer

On Wed, Dec 21, 2016 at 7:07 PM, rosiealice notifications@github.com wrote:

Hi Jennifer,

So, it should be set up to handle negative NPP in general, mostly by extracting that C from the storage pool - obviously, that's a thing that's normal in winter/droughts. The question that came up for evergreen vegetation is whether to a) cease leaf turnover or b) extract C from the store pool, so the allocation scheme is set up to allow for prioritization wherever the 'leaf_stor_priority' shows up.

Having said that, I don't know if the tissue-specific NPP diagnostics are set up to figure this out. I guess that in principle, if the leaves were using up carbon from their own stores, their mass would decline, and if you were very pedantic about measuring pools & fluxes, etc. that should show up? Of course, no-one would ever do that because leaf harvests are destructive, but I don't think a negative productivity should be actually impossible?

On 21 December 2016 at 17:52, Jennifer Holm notifications@github.com wrote:

Summary of Issue:

When running FATES in a northern CA site for 200 years, using either needleleaf evergreen tree or broadleaf evergreen temperate tree PFT, there is a cyclical occurrence of leaf_npp becoming negative (for the period of a couple months out of the year) which then makes total npp become negative. I wanted to create this issue for a couple reasons; 1) to start a discussion on if it seems plausible for NPP, specifically leaf NPP, to be negative? Probably yes, due to high respiration, resorption and pulling from storage pools. 2) to highlight and document as a potential issue to look into about the carbon allocation scheme in general in FATES.

I haven't fully investigated why leaf_npp becomes negative but it seems related to the maintenance demand becoming large, and larger than the available NPP. Question to the group - should we look into the instances when maintenance demand becomes larger than the available NPP (therefore carbon loss, no allocation of carbon to growth) in FATES, or is this a non-issue and correct model behavior? Specifically FATES might be incorrectly "putting" that loss of carbon into a wrong carbon pool or accounting the carbon balance and carbon allocation in a funny way.

In addition all the other NPP pools are positive (npp_dead, npp_alive, npp_storage, npp_seed), but only npp_leaf is the contributor to the negative total NPP.

There may be some areas in the carbon allocation scheme and algorithms with regards to leaf_md, root_md, and npp_leaf that need to be evaluated. Below is some of the code that calculates npp_leaf.

Inside EDPhysiologyMod.F90 =

currentCohort%npp_leaf = min(currentCohort%npp currentCohort%leaf_md/currentCohort%md, & currentCohort%leaf_md EDecophys con%leaf_stor_priority(currentCohort%pft)) Expected behavior and actual behavior:

A negative NPP can realistically occur if respiration overpowers carbon, however the current scheme and procedure of how negative NPP might need to be re-evaluated in the FATES carbon allocation and carbon balance scheme, because a negative leaf pool might not be appropriate. 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:

— 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/164, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ4gnj- vSZ6RilJCJu59tIizncPG4ks5rKcnXgaJpZM4LTiCg .

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 <(303)%20497-1706>

http://www.cgd.ucar.edu/staff/rfisher/

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

-- Jennifer Holm Research Scientist Climate and Ecosystems Sciences Division Lawrence Berkeley National Laboratory 510-495-8083

[rosiealice]

Hi Jennifer,

Thanks for clarifying... So, it should be the case that the leaf pool goes down (for evergreen vegetation) because some of it is not replaced after turnover. There should also be depletion of the storage pool. I don't think there should be direct extraction from the leaf pool though. Note that this isn't necessarily implied by negative leaf_npp, since that's a diagnostic and not used in the actual calculations. So, I guess my question is whether we know that the C is being taken out of the leaf pool, or if it's just the pool responding to the equilibrium of in/out fluxes?

happy holidays/new year/ambiguous in-between phase.

-Rosie

On 22 December 2016 at 10:12, Jennifer Holm notifications@github.com wrote:

Hi all,

Thanks for the comments. I don't think I was completely clear in my original posting. I also agree that a negative NPP is valid, and something that we should expect (especially in higher latitudes for evergreen trees in winter, like Charlie pointed out). So I thought it was kind of neat to confirm that negative NPP occurred in mid latitudes in FATES.

(Not a high priority) but I just wanted to make sure that the algorithm design in the model was set up appropriately for carbon balance and high respiration/non-reproductive seasons. As Rosie mentioned the negative NPP should extract C from the store pool, and I think we should look into this and make sure this is in fact the case. Because from initial investigation it looks like the scheme is not extracting from storage pool, but instead for leaf pool. (but if that is the correct order/path, then this can be a mute point).

Jennifer

On Wed, Dec 21, 2016 at 7:07 PM, rosiealice notifications@github.com wrote:

Hi Jennifer,

So, it should be set up to handle negative NPP in general, mostly by extracting that C from the storage pool - obviously, that's a thing that's normal in winter/droughts. The question that came up for evergreen vegetation is whether to a) cease leaf turnover or b) extract C from the store pool, so the allocation scheme is set up to allow for prioritization wherever the 'leaf_stor_priority' shows up.

Having said that, I don't know if the tissue-specific NPP diagnostics are set up to figure this out. I guess that in principle, if the leaves were using up carbon from their own stores, their mass would decline, and if you were very pedantic about measuring pools & fluxes, etc. that should show up? Of course, no-one would ever do that because leaf harvests are destructive, but I don't think a negative productivity should be actually impossible?

On 21 December 2016 at 17:52, Jennifer Holm notifications@github.com wrote:

Summary of Issue:

When running FATES in a northern CA site for 200 years, using either needleleaf evergreen tree or broadleaf evergreen temperate tree PFT, there is a cyclical occurrence of leaf_npp becoming negative (for the period of a couple months out of the year) which then makes total npp become negative. I wanted to create this issue for a couple reasons; 1) to start a discussion on if it seems plausible for NPP, specifically leaf NPP, to be negative? Probably yes, due to high respiration, resorption and pulling from storage pools. 2) to highlight and document as a potential issue to look into about the carbon allocation scheme in general in FATES.

I haven't fully investigated why leaf_npp becomes negative but it seems related to the maintenance demand becoming large, and larger than the available NPP. Question to the group - should we look into the instances when maintenance demand becomes larger than the available NPP (therefore carbon loss, no allocation of carbon to growth) in FATES, or is this a non-issue and correct model behavior? Specifically FATES might be incorrectly "putting" that loss of carbon into a wrong carbon pool or accounting the carbon balance and carbon allocation in a funny way.

In addition all the other NPP pools are positive (npp_dead, npp_alive, npp_storage, npp_seed), but only npp_leaf is the contributor to the negative total NPP.

There may be some areas in the carbon allocation scheme and algorithms with regards to leaf_md, root_md, and npp_leaf that need to be evaluated. Below is some of the code that calculates npp_leaf.

Inside EDPhysiologyMod.F90 =

currentCohort%npp_leaf = min(currentCohort%npp currentCohort%leaf_md/currentCohort%md, & currentCohort%leaf_md EDecophys con%leaf_stor_priority(currentCohort%pft)) Expected behavior and actual behavior:

A negative NPP can realistically occur if respiration overpowers carbon, however the current scheme and procedure of how negative NPP might need to be re-evaluated in the FATES carbon allocation and carbon balance scheme, because a negative leaf pool might not be appropriate. 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:

— 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/164, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ4gnj- vSZ6RilJCJu59tIizncPG4ks5rKcnXgaJpZM4LTiCg .

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 <(303)%20497-1706> <(303)%20497-1706>

http://www.cgd.ucar.edu/staff/rfisher/

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

-- Jennifer Holm Research Scientist Climate and Ecosystems Sciences Division Lawrence Berkeley National Laboratory 510-495-8083 <(510)%20495-8083>

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

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706

http://www.cgd.ucar.edu/staff/rfisher/

[rgknox]

Thanks for starting this thread Jennifer. I think @rosiealice is on the right track, we have to make sure that the negative in the leaf NPP diagnostic is really reflecting a negative in the actual gains in leaf carbon from NPP (gee I hope so, if not, its on me!).

The leaf NPP diagnostic is calculated in three places. 1) it calculates how much npp is sent to leaves to re-coup turnover loses. In this phase it will send as much npp to the leaves as it possibly can. Then, 2) after it re-fills the whatever storage carbon it can, it will fill the remaining leaf turnover pools. Then, 3) it will calculate how much new leaf tissue needs to be created from growth and then diagnose how much npp is used for leaves.

I think the problem is in 1), this is about line 842 of EDPhysiologyMod.F90:

    ! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools
    ! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

    currentCohort%npp_leaf  = min(currentCohort%npp_acc_hold*currentCohort%leaf_md/currentCohort%md, &
                                  currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))
    currentCohort%npp_froot = min(currentCohort%npp_acc_hold*currentCohort%root_md/currentCohort%md, &
                                  currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))

Here, we see that we are identifying which is a smaller pool, how much turnover needs to be replaced in this phase, or how much npp is available to replace that need. The problem is, that I think we should also force this calculation to be positive with a max(0.0_r8, ... ). I'm still reading through this to get a handle on it, but I think this is where the issue is.

[rgknox]

Note in the snippet below, that we start off the daily carbon balance by subtracting a portion of maintenance demand (%md, note this is NOT respiration, this is maintenance turnover demand) from the total daily NPP. Note also that we subtract the maintenance demand EVEN if we have negative NPP. So in essence, we remove carbon from the negative to replace leaves.

In this scenario, we will draw down the storage biomass pool to accomodate that negative. So in essence, the npp to leaves (in the diagnostic) should be zero since the carbon that is being sent to leaves is not from new production, but is a transfer from storage.

 currentCohort%carbon_balance = currentCohort%npp_acc_hold - &
          currentCohort%md *  EDecophyscon%leaf_stor_priority(currentCohort%pft)

    ! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools
    ! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

    currentCohort%npp_leaf  = min(currentCohort%npp_acc_hold*currentCohort%leaf_md/currentCohort%md, &
                                  currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))
    currentCohort%npp_froot = min(currentCohort%npp_acc_hold*currentCohort%root_md/currentCohort%md, &
                                  currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))

    if (Bleaf(currentCohort) > 0._r8)then

       if ( DEBUG ) write(iulog,*) 'EDphys A ',currentCohort%carbon_balance

       if (currentCohort%carbon_balance > 0._r8)then !spend C on growing and storing

          !what fraction of the target storage do we have? 
          frac = max(0.0_r8,currentCohort%bstore/(Bleaf(currentCohort) * EDecophyscon%cushion(currentCohort%pft)))
          ! FIX(SPM,080514,fstore never used ) 
          f_store = max(exp(-1.*frac**4._r8) - exp( -1.0_r8 ),0.0_r8)  
          !what fraction of allocation do we divert to storage?
          !what is the flux into the store?
          currentCohort%storage_flux = currentCohort%carbon_balance * f_store                     

          if ( DEBUG ) write(iulog,*) 'EDphys B ',f_store

          !what is the tax on the carbon available for growth? 
          currentCohort%carbon_balance = currentCohort%carbon_balance * (1.0_r8 - f_store)  
       else  !cbalance is negative. Take C out of store to pay for maintenance respn.
          currentCohort%storage_flux = currentCohort%carbon_balance 
          currentCohort%carbon_balance = 0._r8 
       endif
        currentCohort%storage_flux = 0._r8
       currentCohort%carbon_balance = 0._r8
       write(iulog,*) 'ED: no leaf area in gd', currentCohort%indexnumber,currentCohort%n,currentCohort%bdead, &
             currentCohort%dbh,currentCohort%balive

    endif

My concern however, is that we may have negative storage pools. While this is not a good thing from carbon conservation (assuming I have this all straight), the tree is about to die anyway. I guess as long as we don't switch the sign on the negative storage pool, we aren't violating physical law. When the tree dies it is passed to the litter and CWD pools, as long as the negative storage isnt greater than the structural pool we should be fine.

So I "think" the solution is to just remove the minimum function on that first npp leaf calculation, and remove the side that has the npp_acc part. As far as I can tell, this carbon transfer into leaves and roots happens at all costs, and since the demand is always zero or positive, we don't need the max(0, ) part either.

! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools
! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

    currentCohort%npp_leaf  = currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)
    currentCohort%npp_froot = currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)

[rosiealice]

Yeah, it is possible to have negative storage pools. You're right in that they are imminently going to die. The trees should begin to die before the pool goes negative, but that depends on the timescale between the carbon pool depletion and the rate at which the mortality algorithm can kill a cohort over a given timestep. I'm not sure how to avoid this, since it would probably involve reducing respiration demand if the carbon pools were depleted, which would likely result in some kind of magic immortal trees. I feel like it's a necessary consequence of the individual->cohort scaling problem, but if we can figure out a better way, that would be fine too!

Not sure I've got my head around the npp_leaf calculations sufficiently to have a useful opinion, but your logic seems good to me..

-Rosie

On 28 December 2016 at 12:45, Ryan Knox notifications@github.com wrote:

Note in the snippet below, that we start off the daily carbon balance by subtracting a portion of maintenance demand (%md, note this is NOT respiration, this is maintenance turnover demand) from the total daily NPP. Note also that we subtract the maintenance demand EVEN if we have negative NPP. So in essence, we remove carbon from the negative to replace leaves.

In this scenario, we will draw down the storage biomass pool to accomodate that negative. So in essence, the npp to leaves (in the diagnostic) should be zero since the carbon that is being sent to leaves is not from new production, but is a transfer from storage.

currentCohort%carbon_balance = currentCohort%npp_acc_hold - & currentCohort%md * EDecophyscon%leaf_stor_priority(currentCohort%pft)

! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools
! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

currentCohort%npp_leaf  = min(currentCohort%npp_acc_hold*currentCohort%leaf_md/currentCohort%md, &
                              currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))
currentCohort%npp_froot = min(currentCohort%npp_acc_hold*currentCohort%root_md/currentCohort%md, &
                              currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft))

if (Bleaf(currentCohort) > 0._r8)then

   if ( DEBUG ) write(iulog,*) 'EDphys A ',currentCohort%carbon_balance

   if (currentCohort%carbon_balance > 0._r8)then !spend C on growing and storing

      !what fraction of the target storage do we have?
      frac = max(0.0_r8,currentCohort%bstore/(Bleaf(currentCohort) * EDecophyscon%cushion(currentCohort%pft)))
      ! FIX(SPM,080514,fstore never used )
      f_store = max(exp(-1.*frac**4._r8) - exp( -1.0_r8 ),0.0_r8)
      !what fraction of allocation do we divert to storage?
      !what is the flux into the store?
      currentCohort%storage_flux = currentCohort%carbon_balance * f_store

      if ( DEBUG ) write(iulog,*) 'EDphys B ',f_store

      !what is the tax on the carbon available for growth?
      currentCohort%carbon_balance = currentCohort%carbon_balance * (1.0_r8 - f_store)
   else  !cbalance is negative. Take C out of store to pay for maintenance respn.
      currentCohort%storage_flux = currentCohort%carbon_balance
      currentCohort%carbon_balance = 0._r8
   endif
    currentCohort%storage_flux = 0._r8
   currentCohort%carbon_balance = 0._r8
   write(iulog,*) 'ED: no leaf area in gd', currentCohort%indexnumber,currentCohort%n,currentCohort%bdead, &
         currentCohort%dbh,currentCohort%balive

endif

My concern however, is that we may have negative storage pools. While this is not a good thing from carbon conservation (assuming I have this all straight), the tree is about to die anyway. I guess as long as we don't switch the sign on the negative storage pool, we aren't violating physical law. When the tree dies it is passed to the litter and CWD pools, as long as the negative storage isnt greater than the structural pool we should be fine.

So I "think" the solution is to just remove the minimum function on that first npp leaf calculation, and remove the side that has the npp_acc part. As far as I can tell, this carbon transfer into leaves and roots happens at all costs, and since the demand is always zero or positive, we don't need the max(0, ) part either.

! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools ! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

currentCohort%npp_leaf  = currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)
currentCohort%npp_froot = currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)

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

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706

http://www.cgd.ucar.edu/staff/rfisher/

[rgknox]

I thought about it a little more, and I think that my solution needs to add back in that minimum of the available carbon crossed with the maintenance demand. So the leaf_npp from the first phase of maintenance demand is the maximum of zero and ( the minimum of available and demanded). This takes into account that what is transferred to the maintenance demand can come from both storage and npp, if npp is not large enough to supply all of it. If npp is negative, there is no leaf_npp, and thus all the demand is taken from storage carbon.

In order for the npp partitions to add up to the total npp, and thus pass its check, we currently are setting npp_storage to have a maximum of 0 and the storage transfer. I think it makes more sense for the storage npp to be allowed to be negative, as opposed to allowing leaf_npp to be negative. When total npp is negative, it is the storage pool that is really loosing carbon, not the leaf pool.

Again, I'm only talking about the diagnostic itself, dynamics seem to be doing what is intended. I also agree with you Rosie, it seems like negative storage pools, while not ideal, seem to be sort of necessary right now.

Propose fix:

Line 845 of EDPhysiologyMod:

! Allowing only carbon from NPP pool to account for npp flux into the maintenance pools
    ! ie this does not include any use of storage carbon or balive to make up for missing carbon balance in the transfer

    currentCohort%npp_leaf  = max(0.0_r8,min(currentCohort%npp_acc_hold*currentCohort%leaf_md/currentCohort%md, &
                                  currentCohort%leaf_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)))
    currentCohort%npp_froot = max(0.0_r8,min(currentCohort%npp_acc_hold*currentCohort%root_md/currentCohort%md, &
                                  currentCohort%root_md*EDecophyscon%leaf_stor_priority(currentCohort%pft)))

And on line 873 of EDPhysiologyMod:

currentCohort%npp_store = currentCohort%storage_flux
``

[rgknox]

I've put a little more time into this, and I believe that I have a working solution now that correctly tracks storage carbon as the negative flux that pays back respiration costs in the event that NPP is negative. The balance check during runtime also passes.

However, to make my checks balance out, I had to re-evaluate the strorage carbon flux under the condition of no leaves. At around line 878 of EDPhysiologyMod.F90, we were setting %storage_flux to zero under this scenario. I think we were not paying respiration costs from storage, see fix:

https://github.com/NGEET/ed-clm/compare/master...rgknox:rgknox-leafnpp-diag-fix

@rosiealice, @ckoven et al, could you give a second opinion here?

Note that I am trying to check the carbon balance via the diagnostic sites(s)%cbal_err_tot (which had not been balancing exactly), but I am running into some errors in the output which is causing the netcdf file to freak. But, I am tracking that problem down.

In ChecksBalancesMod.F90 at line ~200, I started printing out the balance terms for each day, I found that sites(s)%fates_to_bgc_this_ts would immediately jump to a very high number, printing them in order:

                sites(s)%totfatesc      sites(s)%totfatesc_old   sites(s)%npp_timeintegrated       sites(s)%tot_seed_rain_flux*SHR_CONST_CDAY   sites(s)%fates_to_bgc_this_ts*SHR_CONST_CDAY  sites(s)%fire_c_to_atm*SHR_CONST_CDAY
 ERR TERMS:   149.00912579306487        148.68180285339346       0.38349237540863162        0.0000000000000000        6.1075523703076798E-002   0.0000000000000000     
 ERR TERMS:   149.37156035031938        149.00912579306487       0.42147682767079558        0.0000000000000000        6.3969159088684169E-002   0.0000000000000000     
 ERR TERMS:   149.68398676330278        149.37156035031938       0.37069739606473551        0.0000000000000000        6.3217292538392394E-002   0.0000000000000000     
 ERR TERMS:   149.90249523001418        149.68398676330278       0.27649385526286407        0.0000000000000000        6.2914365821636703E-002   0.0000000000000000     
 ERR TERMS:   150.07886106925119        149.90249523001418       0.23482911658794359        0.0000000000000000        1.7146535853788455E+243   0.0000000000000000     

[rosiealice]

Thanks Ryan... I hadn't ever put in respiration costs from the storage pool, (for better or worse). Just to clarify.

On 4 January 2017 at 13:03, Ryan Knox notifications@github.com wrote:

I've put a little more time into this, and I believe that I have a working solution now that correctly tracks storage carbon as the negative flux that pays back respiration costs in the event that NPP is negative. The balance check during runtime also passes.

However, to make my checks balance out, I had to re-evaluate the strorage carbon flux under the condition of no leaves. At around line 878 of EDPhysiologyMod.F90, we were setting %storage_flux to zero under this scenario. I think we were not paying respiration costs from storage, see fix:

master...rgknox:rgknox-leafnpp-diag-fix https://github.com/NGEET/ed-clm/compare/master...rgknox:rgknox-leafnpp-diag-fix

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

--

Dr Rosie A. Fisher

Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706

http://www.cgd.ucar.edu/staff/rfisher/

[rgknox]

@rosiealice and I just had a phone call, and we realized that the calculations of storage fluxes and carbon balances when bleaf(cohort)<0 is inconsequential. bleaf(cohort)<=0 should be a failure, as it means that cohort trimming is zero or the target leaf biomass is zero, which should be impossible. I had thought this was the actual leaf biomass, but it is the target leaf biomass. I will update the code and test accordingly.