Deactivate history fields in SP mode by mvdebolskiy · Pull Request #1568 · NGEET/fates

mvdebolskiy · 2026-05-11T19:46:03Z

Use a bool switch to deactivate default fields in SP-mode, so that on the HLM-side long hist_fexl* are not used.

Description:

See above

Collaborators:

Expectation of Answer Changes:

For SP-test a few extra fields will be deactivated, since f.e. in CTSM tests, the FATES-SP usermod has not been updated in a while.

Description of generative AI usage (as necessary)

None.

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
Describe use of generative AI (if 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:

Only field list will change for SP tests with:

 Could not find match for file1 variable FATES_SEED_BANK_LUPF in file2
 Could not find match for file1 variable FATES_SEED_BANK_PF in file2

Tested with ctsm's FatesColdSatPhen testmod. with commenting out exclude in the fates-sp usermod vs default tag. Test with FatesCold and removing hist_fincl and empty_tapes showed no diffs.

*CTSM (or) E3SM (specify which) test hash-tag: ctsm5.4.038

*CTSM (or) E3SM (specify which) baseline hash-tag: ctsm5.4.038

*FATES baseline hash-tag: sci.1.92.4_api.45.0.0

Test Output:

rgknox · 2026-05-14T16:57:25Z

Love this change

rosiealice · 2026-05-14T17:15:18Z

       call this%set_history_var(vname='FATES_FROOTC', units='kg m-2',            &
            long='total biomass in live plant fine roots in kg carbon per m2',    &
-            use_default='active', avgflag='A', vtype=site_r8, hlms='CLM:ALM',     &
+            use_default=trim(drop_in_sp), avgflag='A', vtype=site_r8, hlms='CLM:ALM',     &


These allometric C structure variables are, I think, relevant/used in SP mode. The cohort is defined based on the height and the other pools are set accordingly. So there should be valid values for VEGC, SAPWOODC, FROOTC, STRUCTC, NONSTRUCTC

See comment below.

rosiealice · 2026-05-14T17:16:00Z

          call this%set_history_var(vname='FATES_VEGC_PF', units='kg m-2',           &
               long='total PFT-level biomass in kg of carbon per land area',         &
-               use_default='active', avgflag='A', vtype=site_pft_r8, hlms='CLM:ALM', &
+               use_default=trim(drop_in_sp), avgflag='A', vtype=site_pft_r8, hlms='CLM:ALM', &


This should exist in SP mode.

@rosiealice but it currently does no.
https://github.com/ESCOMP/CTSM/blob/e1f563b8345400d33421263f05b237f13e6b0e3d/cime_config/usermods_dirs/clm/fates_sp/user_nl_clm#L13

I don't think we calculate it though.

WHen in SP or ST3 mode, we perform a bypass of the whole allocation algorithm:

https://github.com/NGEET/fates/blob/main/main/EDMainMod.F90#L1133

Without calling it, there is no VEGC. We could certainly improve the bypass though to set VEGC to allometric targets though....

rosiealice · 2026-05-14T17:17:27Z

          call this%set_history_var(vname='FATES_LAI_CANOPY_SZ', units = 'm2 m-2',   &
               long='leaf area index (LAI) of canopy plants by size class',         &
-               use_default='active', avgflag='A', vtype=site_size_r8,               &
+               use_default=trim(drop_in_sp), avgflag='A', vtype=site_size_r8,               &


In principle the plants in SP mode do have a height and and LAi and so in theory this has some meaning...

But there is only one size ("SZ") right? I see this diagnostic as not wrong, just unneeded with SP.

I actually think this might be useful, even in SP. since the height bins aren't the height of the plant, but the height of the leaf area distributions of the plants, so there could in principle be some information here

rosiealice · 2026-05-14T17:18:13Z


          call this%set_history_var(vname='FATES_NPLANT_SZ', units = 'm-2',          &
-               long='number of plants per m2 by size class', use_default='active',  &
+               long='number of plants per m2 by size class', use_default=trim(drop_in_sp),  &


This might also be useful as a diagnostic to check that the plants are coming out in the right size class given HTOP...

rosiealice

Looks great @mvdebolskiy ... Thanks for pushing this back.

mvdebolskiy · 2026-05-14T17:21:31Z

@rosiealice I don't quite get the comments. If the variables there "should be active" why are they exluded in the usermod that is getting picked up by FATES-SP compsets? Do you need this variables ouputted all the time you have an SP run, or can they just be requested by user whenever user needs them?

rosiealice · 2026-05-14T17:28:35Z

@rosiealice I don't quite get the comments. If the variables there "should be active" why are they exluded in the usermod that is getting picked up by FATES-SP compsets? Do you need this variables ouputted all the time you have an SP run, or can they just be requested by user whenever user needs them?

Fair enough. It's not critical either way. I guess i just didn't think about these reasons for keeping them last time I went through the variable list (I realize I'm critiquing my own earlier classification effort here, so should have been clearer about that :) ) .

Fix gnu integer logical

rosiealice · 2026-05-22T08:28:26Z

Just for now, none of this is super critical and we can always add these variables back in later if necessary. I think we can pull this PR as it is...

rosiealice

I think this is really OK as it is, for the sake of time. We can always modify the details later, but this is necessary for the whole FATES compset workflow and so it's probably best to include it sooner rather than later (thus retracting my earlier nitpicking over the inclusion of certain fields :) )

ckoven · 2026-05-22T16:34:53Z

I think this is really OK as it is, for the sake of time. We can always modify the details later, but this is necessary for the whole FATES compset workflow and so it's probably best to include it sooner rather than later (thus retracting my earlier nitpicking over the inclusion of certain fields :) )

agreed

Refactor initial seed parameter into two new parameters This creates a new parameter `fates_recruit_init_dbh` to set the initial seedling DBH. Prior to this tag, `fates_recruit_init_density` could enact this functionality by setting a negative value.

glemieux · 2026-06-01T16:16:31Z

Regression testing underway on derecho.

mvdebolskiy · 2026-06-02T07:49:50Z

Btw, this needs an acompaning PR that removes the hist_fexl statement from fates-sp usermod or a PR with refactor for ctsm compsets NorESMhub/CTSM#224 the answers won't be b4b, since there are more fields removed than in the usermod.

wwieder · 2026-06-02T16:37:19Z

Can you remind me, Is this something we want to integrate for the CLM-FATES freeze? If so, is there a CLM side issue or PR that we can use for tracking?

glemieux · 2026-06-02T17:35:28Z

Can you remind me, Is this something we want to integrate for the CLM-FATES freeze? If so, is there a CLM side issue or PR that we can use for tracking?

@wwieder I don't think there is an ctsm-side issue yet. Has there been discussion with the CTSM SE team about adopting the FATES SP mode build namelist BGC flag option that NorESM implemented in the PR NorESMhub/CTSM#224 @mvdebolskiy mentioned above (i.e. moving away from the user_mod setup for FATES-SP complist).
https://github.com/mvdebolskiy/CTSM/blob/fb55d3470691726315d986a63fd9f950e85f59c9/bld/CLMBuildNamelist.pm#L88-L108

I've got a branch just update the user_mod per Matvey's reminder if that's the preference instead.

mvdebolskiy · 2026-06-02T18:02:58Z

@wwieder I've tested my noresm-compsets PR that also reduces some fates usermod burden on derecho and it did not affect clm-test's namelists in aux_clm. The only issue with it is that I need a PR to put drydep and bvoc's into ngeet from NorESM fork, in order to have CTSM-side working. And the last question is how many fates_parameter files we need to maintain. Plus, the initial datasets/landuse forcing is not finalized yet, since we are fixing some bugs with tiny numbers causing balance errors.

glemieux · 2026-06-09T16:23:03Z

Btw, this needs an acompaning PR that removes the hist_fexl statement from fates-sp usermod

This is waiting on approval of ESCOMP/CTSM#4079.

mvdebolskiy added 2 commits May 11, 2026 07:38

add switch and apply

e8eed99

revert FATES_VEGC_SZ

ae344c3

github-project-automation Bot added this to FATES Pull Request Planning and Status May 11, 2026

github-project-automation Bot moved this to Finding Reviewers in FATES Pull Request Planning and Status May 11, 2026

glemieux requested a review from adrifoster May 14, 2026 16:21

glemieux moved this from Finding Reviewers to Under Review in FATES Pull Request Planning and Status May 14, 2026

rosiealice reviewed May 14, 2026

View reviewed changes

mvdebolskiy commented May 19, 2026

View reviewed changes

Comment thread main/FatesHistoryInterfaceMod.F90 Outdated

Update main/FatesHistoryInterfaceMod.F90

6ae088d

Fix gnu integer logical

mvdebolskiy requested review from ckoven, rgknox and rosiealice May 22, 2026 08:26

rosiealice reviewed May 22, 2026

View reviewed changes

rosiealice approved these changes May 22, 2026

View reviewed changes

ckoven approved these changes May 22, 2026

View reviewed changes

glemieux moved this from Under Review to Final Testing in FATES Pull Request Planning and Status May 26, 2026

glemieux moved this from Final Testing to Hold in FATES Pull Request Planning and Status Jun 2, 2026

glemieux mentioned this pull request Jun 4, 2026

Remove variables to exclude for fates_sp user mod ESCOMP/CTSM#4079

Open

6 tasks

glemieux moved this from Hold to Final Testing in FATES Pull Request Planning and Status Jun 11, 2026

Conversation

mvdebolskiy commented May 11, 2026 • edited by glemieux Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description:

Collaborators:

Expectation of Answer Changes:

Description of generative AI usage (as necessary)

Checklist

Documentation

Test Results:

Uh oh!

rgknox commented May 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rosiealice May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rosiealice left a comment

Choose a reason for hiding this comment

Uh oh!

mvdebolskiy commented May 14, 2026

Uh oh!

rosiealice commented May 14, 2026

Uh oh!

Uh oh!

rosiealice commented May 22, 2026

Uh oh!

rosiealice left a comment

Choose a reason for hiding this comment

Uh oh!

ckoven commented May 22, 2026

Uh oh!

glemieux commented Jun 1, 2026

Uh oh!

mvdebolskiy commented Jun 2, 2026

Uh oh!

wwieder commented Jun 2, 2026

Uh oh!

glemieux commented Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mvdebolskiy commented Jun 2, 2026

Uh oh!

glemieux commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

mvdebolskiy commented May 11, 2026 •

edited by glemieux

Loading

rosiealice May 14, 2026 •

edited

Loading

glemieux commented Jun 2, 2026 •

edited

Loading