Deciduous vegetation declines due to reset in L2FR during leaf-off.

[sharma-bharat]

Vegetation decline in CNP spinups: Is resetting of L2FR value after senescence a probable reason?

Description:

We see that the GPP, NPP, and LAI were declining rapidly during the AD Spinups during the RD and ECA runs both for evergreen needleleaf and cold-deciduous plant functional type but not for Carbon only runs (see Fig 1).

Increasing the initial period of supplemental N supported vegetation productivity but the decline in productivity happens when supplemental N is stopped.

Partial improvement was seen by commenting the call to dynamic L2FR for initial few decades. We see an increase in vegetation productivity but it was low. Commenting the call to dynamic L2FR throughout the AD spinup lead to increase in GPP but it was still much lower than expected (Fig 2).

We think that Fineroot biomass (FR) is dropping to near zero during the winter in the CNP simulations, especially in deciduous PFT when leaf-off is triggered (Fig 3). Near-zero winter FR might be preventing uptake of available N during periods of no leaves (or close enough). The big increase in FR each year will add a significant amount of real N demand (i.e. what's required for growth), contributing to the rapid depletion of the store.

We also noticed that the L2FR was resetting to default parameter L2FR after every senescence event. Thus, L2FR value of previous timestep was not used in resource allocation (as intended by subroutine CNPAdjustFrootTargets) in following timestep.

In summary,

• L2FR in each cohort's data structure is initialized with the value from the parameter file, the biomass targets in the CNP allocation routine are initially set here, before a first round of growth happens in CNPStatureGrowth, which happens before dynamic l2fr and target FR biomass is updated in another later second round of growth in CNPAllocateRemainder.

• L2FR is reset after every senescence event.

• Solution (results in Fig 4):

  • turning the dynamic L2FR off during the supplemental N period by conditional call to CNPAdjustFRootTargets on this line (see Code 1 below).

  • Change how l2fr is read in physiology code from this to Code 2 below.
    Code 1:

call get_curr_date(yr, mon, day, sec)                                       
if (spinup_state == 1 .and. yr .gt. nyears_ad_carbon_only) then             
    call this%CNPAdjustFRootTargets(target_c,target_dcdd)                   
else if (spinup_state /= 1) then                                                                                                                                                                                   
    call this%CNPAdjustFRootTargets(target_c,target_dcdd)                   
end if 

Code 2:

l2fr = currentCohort%l2fr

Figures

Fig 1: GPP, NPP, and AR in ad spins for cold deciduousPFT during Carbon only (top) and RD run (bottom). Similar plots are for needleleaf evergreen PFT.

Fig 2: GPP, NPP, AR in ad spins for cold-deciduous PFT during RD Run with dynamic L2FR (default) and without dynamic L2FR.

Fig 3: Leaf, Fineroot, and Store Carbon during the first 30 years of ad spinups for Carbon only (top), RD (middle), and ECA (bottom) runs for cold-deciduous PFT.

Fig 4: GPP, NPP, and AR in ad spins for RD using cold deciduous PFT (top) and needleleaf evergreen PFT (bottom). Similar plots are for ECA.

Collaborators:

Anthony Walker, ORNL (@walkeranthonyp)
Daniel Ricciuto, ORNL (@dmricciuto)

Expectation of Answer Changes:

Checklist

If this is your first time contributing, please read the CONTRIBUTING document.

All checklist items must be checked to enable merging this pull request:

Contributor

• The in-code documentation has been updated with descriptive comments
• The documentation has been assessed to determine if updates are necessary

Integrator

• FATES PASS/FAIL regression tests were run
• Evaluation of test results for answer changes was performed and results provided
• FATES-CLM6 Code Freeze: satellite phenology regression tests are b4b

If satellite phenology regressions are not b4b, please hold merge and notify the FATES development team.

Documentation

• Technical Note update:
• User's Guide update:

Test Results:

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag: v2.1.0-13087-ge9afb7cb13

FATES baseline hash-tag: sci.1.68.2_api.31.0.0

Test Output:

[rgknox]

I think these changes make a lot of sense @sharma-bharat . Both of them. Very excited to see this implemented!!! My CNP work used evergreens, so this never came up in my simulations or testing.

Since FATES code needs to be host agnostic, it can't directly reference ELM data structures. @glemieux and I can work with you to update the code so that we pass the spin-up state and timing information from the host (ELM/CLM) to FATES as an argument.

[sharma-bharat]

Hi Ryan, Thank you for this great update. I am very happy to hear that, we were able to contribute a little to FATES development. I will be happy to work with you to figure out a way to pass on timing information to FATES which is host agnostic. Thanks, Bharat

…

On Tue, Mar 11, 2025 at 1:06 PM Ryan Knox ***@***.***> wrote: I think these changes make a lot of sense @sharma-bharat <https://github.com/sharma-bharat> . Both of them. Very excited to see this implemented!!! My CNP work used evergreens, so this never came up in my simulations or testing. Since FATES code needs to be host agnostic, it can't directly reference ELM data structures. @glemieux <https://github.com/glemieux> and I can work with you to update the code so that we pass the spin-up state and timing information from the host (ELM/CLM) to FATES as an argument. — Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHDBZWYFPNWDOM4FOFHCGHD2T4J3DAVCNFSM6AAAAABYSJDLP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJVGEYDCMRSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: rgknox]*rgknox* left a comment (NGEET/fates#1353) <#1353 (comment)> I think these changes make a lot of sense @sharma-bharat <https://github.com/sharma-bharat> . Both of them. Very excited to see this implemented!!! My CNP work used evergreens, so this never came up in my simulations or testing. Since FATES code needs to be host agnostic, it can't directly reference ELM data structures. @glemieux <https://github.com/glemieux> and I can work with you to update the code so that we pass the spin-up state and timing information from the host (ELM/CLM) to FATES as an argument. — Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHDBZWYFPNWDOM4FOFHCGHD2T4J3DAVCNFSM6AAAAABYSJDLP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJVGEYDCMRSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thanks, Bharat

[glemieux]

This will need to be made agnostic to host land model. Since the different host land models handle the spin up a little differently, I'm going to generate an e3sm PR to add a fates global variable in the interface module to be passed to fates to check here.

[sharma-bharat]

Thanks Gregory for working on it!

Since you are taking a lead on the next step, do need to take any further action on this PR? I do see an option for Resolve conflicts.

[glemieux]

Status update: This needs testing once sharma-bharat#1 has been merged, which itself needs e3sm to be brought up to date with API39.

[sharma-bharat]

Thanks Greg for the update! Looking forward to the next update.

…

On Fri, Apr 4, 2025 at 6:54 PM Gregory Lemieux ***@***.***> wrote: Status update: This needs testing once sharma-bharat#1 <sharma-bharat#1> has been merged, which itself needs e3sm to be brought up to date with API39. — Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHDBZW7WGMDX27DOSTT2UTD2X4ETVAVCNFSM6AAAAABYSJDLP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZZHA3DSMRTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: glemieux]*glemieux* left a comment (NGEET/fates#1353) <#1353 (comment)> Status update: This needs testing once sharma-bharat#1 <sharma-bharat#1> has been merged, which itself needs e3sm to be brought up to date with API39. — Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHDBZW7WGMDX27DOSTT2UTD2X4ETVAVCNFSM6AAAAABYSJDLP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZZHA3DSMRTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thanks, Bharat

[rgknox]

we can clean up and remove these comments

[glemieux]

Status update: This needs testing once sharma-bharat#1 has been merged, which itself needs e3sm to be brought up to date with API39.

@sharma-bharat e3sm is up to date with API 39 now (i.e. E3SM-Project/E3SM#6918 has been merged into e3sm master). I've updated the e3sm pull request that should be used in conjunction with your changes here and the ones @rgknox and I proposed in sharma-bharat#1. Would you test run your branch with sharma-bharat#1 merged in using the e3sm branch in E3SM-Project/E3SM#7182?