Repository navigation
Should some compsets/tests use DGLC%NOEVOLVE rather than SGLC? #1618
Description
We talked about this in today's CSEG meeting, but couldn't have a clear answer there. So I'm adding it here so it isn't lost. This probably needs input from both the land-ice folks as well as CAM folks.
CAM compsets use stub glacier SGLC, but we wondered if they should use DGLC%NOEVOLVE. The fully coupled compsets now use DGLC, but will be converted to using CISM.
For consistency with the fully coupled compsets, it's possible that DGLC should be used rather than SGLC. It would be a minor change to answers, and would have a small performance impact.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
ekluzek commentedon Jul 14, 2026
Part of the reason I thought this was important was that from the CTSM tech note, multi-elevation glaciers wouldn't be turned on without DGLC. But, this might be incorrect and if so the importance of this would be diminished. This would be a bigger issue in that case as then F cases run with SGLC couldn't be used to startup CISM. So I will figure that out and report back.
ekluzek commentedon Jul 15, 2026
The part that I had misinterpreted in the CTSM Tech. note is discussed here:
ESCOMP/CTSM#4110 (comment)
As such this isn't as important as I originally thought. However, it still may be worthwhile to do this in order to make CAM compsets more consistent with fully coupled compsets. So I think it's still worth discussing.
cacraigucar commentedon Jul 21, 2026
@adamrher and @PeterHjortLauritzen - please look into this
cacraigucar commentedon Aug 11, 2026
@PeterHjortLauritzen and @adamrher - could you please check this?
adamrher commentedon Aug 11, 2026
We should convert all/most F-compsets from SGLC to DGLC%NOEVOLVE for the CESM3 release. The history of this issue is that the F-cases previously had CISM%NOEVOLVE, but this was causing slow build times and calendar discrepancies w/ CISM. The F-cases were subsequently converted to use SGLC in this PR #480. If you read the corresponding issue #204, the long-term fix is to use DGLC in the F-cases, but that was not available at the time. DGLC is now available and so this should be done now so that the model generates surface mass balances over ice sheet points. I would use the 480 PR as a guide to which compsets to convert, and additionally I think all cam7 F-compsets should be converted as well.
@ekluzek are the surface datasets using the new glacier dataset, as suggested here: #204 (comment)?
@whlipscomb @Katetc
cacraigucar commentedon Aug 11, 2026
We need to wait for CMEPS/CDEPS PRs from @billsacks to fix the BFBFLAG before we make this move
ekluzek commentedon Aug 12, 2026
@adamrher
Yes, there was a big set of glacier changes that went into the ctsm5.2 surface datasets, and a smaller set in the ctsm5.3 surface datasets, and those carried forward into ctsm5.4 surface datasets. So the things talked about in the comment above would've been in either the ctsm5.2 or ctsm5.3 changes. So they are now in.
adamrher commentedon Aug 13, 2026
Thanks for confirming, @ekluzek. I expect that swapping SGLC for DGLC%NOEVOLVE will change answers, in particular the surface energy balance calculation over glacier mec points.
ekluzek commentedon Aug 13, 2026
Yep, answers are different for I compset over Greenland, so they'll be different for F compsets as well. And so for F compsets the differences will propagate elsewhere. The mask for where the Greenland glacier is and the Glacier topographic height is slightly different when you use DGLC vs. SGLC. Neither change in time -- but it does change when compared to SGLC compsets.
billsacks commentedon Sep 17, 2026
PRs to get bit-for-bit answers with changing processor count when using DGLC:
billsacks commentedon Sep 18, 2026
Those PRs have been merged now.
adamrher commentedon Sep 19, 2026
Thanks @billsacks. We'll move forward on resolving this issue.