Add default handling for fates firemodes in lightning resolution #3606

mvdebolskiy · 2025-11-13T16:04:30Z

Description of changes

Make CLMBuildNamelist.pm read defaults for fates_spitfire_mode and use_fates_managed_fire before they are first used in setup_cmdl_fire_light_res.
Right now, changing defaults in namelist_defaults_ctsm.xml will result in incorrect lightning streams namelists if fates_spitfire_mode>2. Right now we do not have these values by defaults + Fates testmod explicitly sets fates_spitfire_mode=1 in the user_nl_clm.

Specific notes

This is not necessarily needed right now (since we are not updating defaults here), however, if in the future, running fates_spitfire_mode with lightning data will become default (hopefully), without this PR, changing defaults will be useless.

Contributors other than yourself, if any:

@rosiealice @JessicaNeedham @maritsandstad @kjetilaas

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)?

No

Any User Interface Changes (namelist or namelist defaults changes)?

No

Does this create a need to change or add documentation? Did you do so?

No

Testing performed, if any:

Since to test this, one needs to change namelist_defaults_ctsm.xml and Fates testmod, there is a branch: https://github.com/mvdebolskiy/CTSM/tree/spit-ligh-test

Tested namelist building with this branch by making baselines first with ctsm5.3.084:

./create_test SMS_D_Ld2.f45_f45_mg37.I2000Clm60FatesSpRsGs.derecho_gnu.clm-FatesColdSatPhen SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold SMS_D_Ld2.f45_f45_mg37.I2000Clm60BgcCrop.derecho_gnu.clm-coldStart SMS_D_Ld2.f45_f45_mg37.I2000Clm60Sp.derecho_gnu.clm-nofireemis  -t no_sptfr --project CESM0029 --walltime 00:20:00 -o --namelists-only -g nml_defaults --baseline-root /glade/derecho/scratch/mvdebolskiy/bsltmp

Then checking out testing branch and:

./create_test SMS_D_Ld2.f45_f45_mg37.I2000Clm60FatesSpRsGs.derecho_gnu.clm-FatesColdSatPhen SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold SMS_D_Ld2.f45_f45_mg37.I2000Clm60BgcCrop.derecho_gnu.clm-coldStart SMS_D_Ld2.f45_f45_mg37.I2000Clm60Sp.derecho_gnu.clm-nofireemis  -t def4sptfr --project CESM0029 --walltime 00:20:00 -o --namelists-only -c nml_defaults --baseline-root /glade/derecho/scratch/mvdebolskiy/bsltmp

The results:

PASS SMS_D_Ld2.f45_f45_mg37.I2000Clm60BgcCrop.derecho_gnu.clm-coldStart SETUP
    Case dir: /glade/derecho/scratch/mvdebolskiy/SMS_D_Ld2.f45_f45_mg37.I2000Clm60BgcCrop.derecho_gnu.clm-coldStart.C.def4sptfr
PASS SMS_D_Ld2.f45_f45_mg37.I2000Clm60FatesSpRsGs.derecho_gnu.clm-FatesColdSatPhen SETUP
    Case dir: /glade/derecho/scratch/mvdebolskiy/SMS_D_Ld2.f45_f45_mg37.I2000Clm60FatesSpRsGs.derecho_gnu.clm-FatesColdSatPhen.C.def4sptfr
PASS SMS_D_Ld2.f45_f45_mg37.I2000Clm60Sp.derecho_gnu.clm-nofireemis SETUP
    Case dir: /glade/derecho/scratch/mvdebolskiy/SMS_D_Ld2.f45_f45_mg37.I2000Clm60Sp.derecho_gnu.clm-nofireemis.C.def4sptfr
NLFAIL SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold (but otherwise OK) SETUP
    Case dir: /glade/derecho/scratch/mvdebolskiy/SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold.C.def4sptfr
test-scheduler took 5.854830980300903 seconds

Expected NLFAIL:

2025-11-13 08:58:00: NLCOMP
Comparison failed between '/glade/derecho/scratch/mvdebolskiy/SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold.C.def4sptfr/CaseDocs/lnd_in' with '/glade/derecho/scratch/mvdebolskiy/bsltmp/nml_defaults/SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.derecho_gnu.clm-FatesCold/CaseDocs/lnd_in'
  BASE: fates_spitfire_mode = 1
  COMP: fates_spitfire_mode = 4
Differences in namelist 'light_streams':
  found extra variable: 'lightngmapalgo'
  found extra variable: 'stream_fldfilename_lightng'
  found extra variable: 'stream_meshfile_lightng'
  found extra variable: 'stream_year_first_lightng'
  found extra variable: 'stream_year_last_lightng'

Which means, setting fates_spitfire_mode=4 in defaults for fates makes light_streams namelist to get populated.

ekluzek

I'm really glad you noticed this and figured out a solution! Thanks for making this PR so we can fix this.

I have a couple small things I'd like to see us improve on. I'm suggesting I do those and then have you review and approve the changes. Let me know if that sounds like a reasonable process to you.

ekluzek · 2025-11-13T20:34:00Z

bld/CLMBuildNamelist.pm

  if ( &value_is_true($nl->get_value('use_cn')) ) {
     add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, 'fire_method');
  }
+


I think it makes sense for this to go here. But, I also think that the call to setup_logic_fates could be moved in front of this as an alternative way to do it. Since, the lightning resolution for fire is now used for both BGC and FATES I think we should add more comments to the header about this being the case. This was originally designed as only being for BGC and not FATES. So it would be good to clarify that in the header and some of the comments in the code.

I was thinking the order could be changed, but fates_spitfire_mode isn't set until much later. So I don't see a way to merely change the order of the calls to make this work. You might have already tested that as the easiest solution.

In any case since both FATES and BGC need to determine the lightning resolution, they both need to be taken into account here so this change makes sense.

The other thing I realized is that to protect against reordering going wrong -- we can add some assert statements to the subroutines to ensure the needed things are appropriately set. It would be simple to add a few statements to start doing that.

So @mvdebolskiy there's a couple small things that I can see doing that would be good to bring in with this. I suggest the way forward, would be for me to push to your branch -- but have you look over my changes at the end and make sure you approve. I could also give you some instructions and have you implement it -- and then go back and forth to get it right. But, I think it would be easier to have me do those couple things here. So how does that sound for process?

mvdebolskiy · 2025-11-14T12:30:46Z

@ekluzek you can push into here, it's totaly fine. I've added checks for vars not being defined yet, before reading in defaults.
With regards to moving setup_logic_fates, I don't think it's necessary, since light_res processing is done due to command line, while all the fates stuff has little to do with cmdl. It's only spitfire mode that needs to be checked and look for a default because ligh_res is getting set.

ekluzek · 2025-11-17T17:28:07Z

bld/CLMBuildNamelist.pm

+
+  # we have to process defaults for fates fire modes before and not in setup_logc_fates, however, they should not be defined for use_cn or other bgc
+  if ( &value_is_true($nl->get_value('use_fates')) ) {
+     if ( ! defined($nl->get_value('use_fates_managed_fire')) ) {


This line here and in 1037 can be removed.

add default handling for fates firemodes in lightning resolution

04d6941

mvdebolskiy requested a review from ekluzek November 13, 2025 16:04

mvdebolskiy changed the base branch from master to b4b-dev November 13, 2025 17:24

mvdebolskiy added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Nov 13, 2025

wwieder added bfb bit-for-bit and removed next this should get some attention in the next week or two. Normally each Thursday SE meeting. labels Nov 13, 2025

wwieder assigned ekluzek Nov 13, 2025

ekluzek added this to LMWG: Sprint Planning Board Nov 13, 2025

github-project-automation bot moved this to Todo in LMWG: Sprint Planning Board Nov 13, 2025

ekluzek requested changes Nov 14, 2025

View reviewed changes

add checks for the vars not being already defined.

c3cb928

ekluzek added this to CTSM: Upcoming tags Nov 17, 2025

github-project-automation bot moved this to Ready to start (or start again) in CTSM: Upcoming tags Nov 17, 2025

github-project-automation bot moved this from Ready to start (or start again) to Stalled (needs review, blocked etc.) in CTSM: Upcoming tags Nov 17, 2025

ekluzek moved this from Stalled (needs review, blocked etc.) to In progress - b4b-dev in CTSM: Upcoming tags Nov 17, 2025

ekluzek reviewed Nov 17, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add default handling for fates firemodes in lightning resolution #3606

Add default handling for fates firemodes in lightning resolution #3606

Uh oh!

mvdebolskiy commented Nov 13, 2025

Uh oh!

ekluzek left a comment

Uh oh!

ekluzek Nov 13, 2025

Uh oh!

ekluzek Nov 13, 2025

Uh oh!

ekluzek Nov 14, 2025

Uh oh!

ekluzek Nov 14, 2025

Uh oh!

mvdebolskiy commented Nov 14, 2025

Uh oh!

ekluzek Nov 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Add default handling for fates firemodes in lightning resolution #3606

Are you sure you want to change the base?

Add default handling for fates firemodes in lightning resolution #3606

Uh oh!

Conversation

mvdebolskiy commented Nov 13, 2025

Description of changes

Specific notes

Uh oh!

ekluzek left a comment

Choose a reason for hiding this comment

Uh oh!

ekluzek Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

ekluzek Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

ekluzek Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

ekluzek Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

mvdebolskiy commented Nov 14, 2025

Uh oh!

ekluzek Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants