Skip to content

added new coupling mode for noresm#677

Open
mvertens wants to merge 3 commits into
ESCOMP:mainfrom
mvertens:feature/add_noresm_coupling_mode_to_escomp
Open

added new coupling mode for noresm#677
mvertens wants to merge 3 commits into
ESCOMP:mainfrom
mvertens:feature/add_noresm_coupling_mode_to_escomp

Conversation

@mvertens

Copy link
Copy Markdown
Collaborator

Description of changes

Added new valid value to noresm to the COUPLING_MODE xml variable

Specific notes

This change permits namelist values for coupling_mode to now include noresm. Conditionals throughout the code now can test for both noresm and cesm.
This xml variable can also now be included in CDEPS config variables to distinguish between noresm and cesm settings.
Not that this PR also will need to be included for upcoming WW3 PRs from noresm to cesm.

Contributors other than yourself, if any:

CMEPS Issues Fixed:

Are changes expected to change answers? bfb

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

Testing performed

TBD

@billsacks billsacks left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, though I'm curious how you're going to set COUPLING_MODE correctly for noresm and how, if at all, this will interact with CIME_MODEL.

@mvertens

Copy link
Copy Markdown
Collaborator Author

This is one thing that needs to be different for cesm and noresm. The default for CMEPS in noresmhub will be noresm and the default for cmeps in ESCOMP will be cesm. So at this point it does not interact with CIME_MODEL - which is a much bigger lift. For noresm - this will still be CIME_MODEL will still be cesm. Hopefully with the CIME refactor it will be easier to pull that out.

@ekluzek ekluzek left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me as well. It all looks correct to me. I didn't see anything of concern in skimming over the code, other than I'm wondering about if some of the logic statements need paranthesis (even if just for clarity).

Comment thread mediator/med_phases_prep_ice_mod.F90 Outdated
Comment thread mediator/med_phases_prep_ocn_mod.F90 Outdated
mvertens and others added 2 commits July 14, 2026 23:10
Co-authored-by: Erik Kluzek <ekluzek@users.noreply.github.com>
Co-authored-by: Erik Kluzek <ekluzek@users.noreply.github.com>
@billsacks

Copy link
Copy Markdown
Member

Unless my eyes are playing tricks on me, I think the last two commits were unnecessary: I think these .or. expressions were already parenthesized and now they are doubly-parenthesized. That's not really a problem, just unnecessarily parenthetical.

@mvertens as far as I'm concerned, go ahead and merge this when you're ready.

@billsacks

Copy link
Copy Markdown
Member

@mvertens - oh, I remembered I was going to send you a test you could run to confirm that this is bit-for-bit for CESM.

I'd suggest ERS_Ld5.ne30pg3_t232.B1850C_LTso.derecho_intel.allactive-defaultio

You can run this from cesm3_0_alpha09d with this CMEPS update, and compare against the baselines here:

/glade/campaign/cesm/cesmdata/cesm_baselines

(That's the default baseline root for CESM.)

@billsacks

Copy link
Copy Markdown
Member

@mvertens - Actually, I'll just go ahead and run that test for you while I'm thinking of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants