Update pe layouts

[mnlevy1981]

Description of changes

Support tx2_3v3 grid for out-of-the-box layouts, and improve the MT+MARBL layout to match current development runs

Fixes #422
Fixes #423

User interface changes?: No

Testing performed (automated tests and/or manual tests): I created a new case with ne30pg3_t233_wg37_gris4 grid and verified env_run.xml is the same (modulo a <comment> line) as env_mach_pes.xml in run 377.

$ diff -u  /glade/campaign/cesm/cesmdata/cseg/runs/cesm2_0/b.e30_alpha09d_m.B1850C_MTso_Gris_Marbl.ne30_t233_wgx3.377/env_mach_pes.xml .
--- /glade/campaign/cesm/cesmdata/cseg/runs/cesm2_0/b.e30_alpha09d_m.B1850C_MTso_Gris_Marbl.ne30_t233_wgx3.377/env_mach_pes.xml	2026-08-09 15:06:18.100389000 -0600
+++ ./env_mach_pes.xml	2026-09-08 17:19:35.019982879 -0600
@@ -24,7 +24,6 @@
     The following values should not be set by the user since they'll be
     overwritten by scripts: TOTALPES, NTASKS_PER_INST
     </header>
-  <comment>none</comment>
   <group id="mach_pes">
     <entry id="ESMF_AWARE_THREADING" value="FALSE">
       <type>logical</type>

[mnlevy1981]

This should be two commits, not 55... do I have the wrong target branch? I'm confused by all the "merge branch" commits that don't seem to actually add any changes

[briandobbins]

I'm guessing you were on the master branch, and not the cesm3.0-alphabranch?

I imagine a simple rebase --onto upstream/cesm3.0-alphabranch would fix it if so, but I'd check where you're pushing from first.

[mnlevy1981]

I created my branch from a fresh checkout of cesm3_0_beta09, but it looks like that tag is on master instead of the alphabranch. Should I recreate this PR on top of cesm3.0-alphabranch or should I point the existing PR to master?

[mnlevy1981]

Also, the two branches are very close but not quite identical. These are the results from git diff remotes/origin/master remotes/origin/cesm3.0-alphabranch:

diff --git a/cime_config/testmods_dirs/allactive/cism/test_coupling/user_nl_clm b/cime_config/testmods_dirs/allactive/cism/test_coupling/user_nl_clm
index 892dcb5..cf7c7fa 100644
--- a/cime_config/testmods_dirs/allactive/cism/test_coupling/user_nl_clm
+++ b/cime_config/testmods_dirs/allactive/cism/test_coupling/user_nl_clm
@@ -2,11 +2,3 @@
  ! This is needed to tell CLM to allow the non-annual-boundary glacier changes that arise
  ! with this testmod.
  for_testing_allow_non_annual_changes = .true.
-
- ! When we have daily rather than annual glacier dynamics (as we do in this testmod, due
- ! to having test_coupling in user_nl_cism), CLM applies the dynbal adjustments in a
- ! single time step rather than spreading them throughout the year. This can cause
- ! sensible heat fluxes of thousands of W m-2, which causes CAM's PBL scheme to blow up.
- ! So force these fluxes to zero for this testmod; this breaks water and energy
- ! conservation in CLM, but should allow the test to pass.
- for_testing_zero_dynbal_fluxes = .true.

[billsacks]

If I remember correctly (which I may not be!), for CESM2, we made the default PE layout significantly smaller than the layout used in the cmip runs. I feel like that's a good idea for the sake of testing. The ideal in my mind is to have the default layout be smaller, and then also define a "large" (or something like that) PE layout if that option is given to create_newcase.

@mnlevy1981 @fischer-ncar @briandobbins - thoughts on this?

[briandobbins]

My idea, though I'd greatly appreciate feedback here, is to have the 'default' (the M size) indeed be smaller than the target CMIP layout.

Since most costs are dictated by the atmosphere, especially with the MTt4s runs, I was thinking of using:

X (or X1) = CAM has 5400 MPI ranks (1 element/core) each with 2-3 vertical/tracer threads (lots of nodes!)
L = CAM has 5400 MPI ranks (1 element/core) but no threading
M = CAM has roughly 1350 - 2700 MPI ranks (2-4 elements/ core) - default, and efficient, but not fast
S = CAM has minimal number of nodes that can run the problem and fit in memory - most efficient, but very slow.

(Typically, CAM-SE gets the best performance when all ranks have the same number of elements -- a decomposition where some ranks have 1 element and others have 2 will be performance-gated by the ones with 2.)

This would require a '--pecount L (or X/X1)' option during case creation for the CMIP runs, but otherwise be more efficient for non-CMIP users. I did look but didn't see a 'PT' option for case creation, Bill, that you mentioned the other day, but also didn't have much time to look. I'll check again when I get a moment.

Thoughts?

[mnlevy1981]

@billsacks As @briandobbins mentioned, I don't think this should be the default layout for the release... but my concern is that right now the layout that comes out of the box tries to squeeze the whole model onto like 6 nodes and the model doesn't run in that configuration. I figured there is currently only one use-case for this compset, and that's the CESM3 development runs - so let's provide the layout being used in those runs (currently by copying an env_run.xml file into every case root) and then we at least have something reasonable out of the box while we think about what other layouts we want to provide