Use reproducible global sums in DGLC when bfbflag is set - #443
Merged
Merged
Conversation
This is effectively identical to a counterpart in CMEPS (in med_global_sums_mod.F90). We need separate copies in each because there isn't a place where we can put a shared copy such that it will be available in both the CESM and UFS builds.
This allows the global sums to be done in a processor-count-independent way if bfbflag is set.
cdeps1.0.108
cdeps1.0.109
They needed to be size-1 arrays for the old use of the ESMF-based reduction. With the new use of dglc_global_sums, they can be scalars.
Member
Author
|
I have done some additional testing, which I have documented in the top-level comment of this PR. |
Katetc
approved these changes
Sep 18, 2026
Katetc
left a comment
Collaborator
There was a problem hiding this comment.
HI Bill, this one is simpler. I didn't do a diff against the global_sums_mod in CMEPS but I'm sure they are very similar, so that helps. I think this one can be merged without issue.
Member
Author
Thanks a lot. I diffed them... the differences are trivial. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
The global sums in DGLC lead to roundoff-level differences with different processor counts. This causes failures in tests - like the ERP test - that check for bit-for-bit results with changing process count.
This PR uses the bfbflag attribute to choose whether to perform global sums in the original way or using shr_reprosum_mod to get bit-for-bit results when changing processor count. This bfbflag attribute is added in ESCOMP/CMEPS#704, and the changes in this PR are connected to that CMEPS PR. By default we still use the original way, both for better performance and because UFS doesn't have shr_reprosum_mod. (Note that an error will be raised if trying to set bfbflag with UFS.) Some CIME tests, such as the ERP test, turn on BFBFLAG so will leverage this new behavior.
The global sums routine is duplicated between CMEPS and CDEPS. I don't like that. But I couldn't see a good alternative. Alternatives I considered were:
Most of the changes were written by Claude, but with detailed guidance and careful reviews by myself.
Specific notes
Contributors other than yourself, if any:
CDEPS Issues Fixed (include github issue #):
Are there dependencies on other component PRs (if so list):
Are changes expected to change answers (bfb, different to roundoff, more substantial): roundoff-level changes for tests that set BFBFLAG and use DGLC (ERP, PEM, PET, SEQ)
Any User Interface Changes (namelist or namelist defaults changes):
Testing performed (e.g. aux_cdeps, CESM prealpha, etc):
aux_cime_baselines and aux_cdeps in the context of cesm3_0_beta09, with this branch and the CMEPS branch in ESCOMP/CMEPS#704.
All tests pass and are bit-for-bit except expected failures and this test that has roundoff-level changes due to a change in CMEPS:
SMS_Ly2.f09_g17_gris20.T1850Gg.derecho_intel.Also some additional tests to give better test coverage; these included the following (along with some others that were less good tests, so I'm not documenting them here)