testing; ccs_config coarse resolution BHIST (for DART)

[kdraeder]

Background

This is one of 5 related (small) PRs are required to implement coarse-resolution BHIST MCC and ERI tests:

1. CESM,
2. ccs_config,
3. cime,
4. components/cmeps,
5. components/mom/MOM6.

I will include their PR numbers after they've all been assigned.

They have been developed under branch names DART_lowres_{component},
which were branched from a CESM clone copied from @alperaltuntas ;
/glade/work/raeder/Models/cesm3_0_alpha08d_mar13

> git describe --tags
  cesm3_0_alpha08d

which implements a coarse-resolution mom via the new testmod mom/tx10deg.

Fixes Issue:

I did not open a ccs_config issue because the work started in other components and spread to ccs_config.
I'll open one if that helps the workflow.
Otherwise, this PR contributes to fixing encompassing issue ESMCI/cime#4933 and background issue cam ESCOMP/CAM#1482 (closed).
The specific fixes are described in the commit messages.

User interface changes?

Yes (sometimes). In order to run tests of certain sizes parameters in the new testmod
{CESM}/cime_config/testmods_dirs/allactive/DART_BHIST_lowres
must be set according to instructions in .../README_layout

Tests

The changes have passed tests:

MCC_cG.ne3pg3_ne3pg3_t232.BHISTC_LT_DART.derecho_intel.allactive-DART_BHIST_lowres--mom-tx10deg
with ensemble sizes default NINST (3), and small(_C3 explicit), medium(_C14 and _C40).
  small  = all instances fit on one (develop) node
  medium = instances must be spread across >1 (main, cpu) node,
           requiring correct value in MAX_TASKS_PER_NODE
           to prevent an instance from being laid out onto 2 nodes.
  large  = each instance gets whole node(s)

ERI.ne3pg3_ne3pg3_t232.BHISTC_LT_DART.derecho_intel.allactive-DART_BHIST_lowres--mom-tx10deg
ERI_cG_C2_P6.ne3pg3_ne3pg3_t232.BHISTC_LT_DART.derecho_intel.drv-fixes4BHISTSWAV--mom-tx10deg
  drv-fixes4BHISTSWAV was an earlier version of DART_BHIST_lowres.
     It set CLM_BLD_NMLOPTS but not MAX_TASKS_PER_NODE, which was not known to be needed.
     It also set ROF_NCPL, which became unneccessary by the end of development,
     but did not set GLC_NCPL.
  _P6 is spurious; the coarse resolution MOM6 is restricted to 6 tasks.

[billsacks]

@alperaltuntas - since it sounds like @kdraeder adapted these changes from some things you did, would you be able to review this?

[kdraeder]

I've imported the changes to the most recent CESM tag; cesm3_0_alpha09a.
They passed the most challenging ERI and MCC tests I developed using the earlier cesm,
so I'm wondering whether I should somehow update this PR, or close it and open
a new one based on the new CESM.

[alperaltuntas]

@kdraeder Have you made any changes to the resolution definition in your latest sandbox. If not, then I think this PR can be merged as is.

[kdraeder]

@kdraeder Have you made any changes to the resolution definition in your latest sandbox. If not, then I think this PR can be merged as is.

For better or worse, the changes proposed based on the earlier CESM were used in the recent CESM.
Thanks for the review and approval!

[alperaltuntas]

Please remove the conflict markers that got introduced after your latest merge. (And resolve the conflict)

[kdraeder]

@alperaltuntas I believe that I fixed the mistakes, but the PR still says Changes requested.
Am I missing anything?
Also, I synced my fork, but that doesn't show up here as a commit, like it does for (some?)
other components' PRs.

[alperaltuntas]

@kdraeder This PR looks good to me. One heads-up, though: we're pivoting to the new Workhorse ocean grid, tx2_3v3. You may want to add a resolution with that grid as well.

[billsacks]

Thanks, @alperaltuntas .

@kdraeder - Based on @alperaltuntas 's comment, would it make sense to use that newer grid in your test so you're using the standard one that others will be using? If you prefer to stick with this one, that's fine, too.

Either way, as I looked at this PR a bit more, I also have two other requests:

(1) It looks like this new grid is a bit out of place in the file. It appears in the section for ne3pg2 grids. Can you please move the new block to the section with other ne3pg3 grids (with comment, "spectral element grids with 3x3 FVM physics grid"), if you agree?

(2) I appreciate your adding a comment describing the purpose of the grid, but I feel it would be more clear if it said something like, "low-res atm & ocn grid useful for B compset testing, e.g., for DART".

[kdraeder]

we're pivoting to the new Workhorse ocean grid, tx2_3v3.

@alperaltuntas Thanks for this tip!
Do I remember correctly that this grid name represents a grid form, but not necessarily a resolution?
So I can still set up a coarse resolution test case using testmods "mom-tx10deg"?

[kdraeder]

@billsacks I agree with (1) and (2).
I had already done (1) in my alpha9a clone, but had not committed or pushed it yet.
After I hear about the grid form versus resolution from Alper, I'll push these changes.

[kdraeder]

@alperaltuntas Let me know whether this should be new issue somewhere else.
I'm trying to use the t2_3v3 grid (mask), but my CESM can't find the version of ocean_hgrid it wants;
/glade/campaign/cesm/cesmdata/cseg/inputdata/ocn/mom/tx2_3v3/tx10deg/ocean_hgrid_tx10deg_20260219.nc.
The tx10deg directory doesn't exist yet (and there's no tx3deg, which is in tx2_3v2).
Does that need to be generated, or can I copy
tx2_3v2/tx10deg/ocean_hgrid_tx10deg_20260219.nc
into a corresponding t2_3v3 directory?

[alperaltuntas]

@kdraeder Yes, you can still set up a coarse-resolution test case using the mom-tx10deg testmods. Note that we're in the process of adding a proper 2-degree grid that will be officially supported for users, unlike the currently available testmods. As part of that work, I plan to remove the mom-tx3deg testmods at some point, but mom-tx10deg will remain available.
Regarding your last message, please open an issue on MOM_interface and we'll take it from there.

[kdraeder]

@billsacks @alperaltuntas I'm glad to hear that the 10 degree will be available; it's very helpful for testing the large ensembles which DART needs to use.
For now I'll continue to use the t2_3v2 mask+grid in the testing and changes that I push.

[kdraeder]

@billsacks @alperaltuntas
MOM_interface PR #340 fixes the "missing" grid (mask) files problem in t2_3v3.
I'm not feeling a need to retest this, but I'll do that if anyone thinks that would be useful.

[billsacks]

I'm fine with this. I've kind of lost track of the details here, though, so @kdraeder and @alperaltuntas please comment on whether you feel this is ready to merge at this point.

[kdraeder]

It's just an additional conditional print statement, and it works when it should,
so I think the code is ready to merge.

[fischer-ncar]

@alperaltuntas and @billsacks since this grid is intended for a B compset test. Shouldn't the model grid alias be ne3pg3_t232? When I first saw ne3pg3_ne3pg3_t232 I thought it was a typo and was suppose to be ne3pg3_ne3pg3_mt232. Then I got confused when I saw that it was for a B compset test.

[billsacks]

It's just an additional conditional print statement, and it works when it should, so I think the code is ready to merge.

@kdraeder - I think you're referring to a different PR. This one adds a new grid.

since this grid is intended for a B compset test. Shouldn't the model grid alias be ne3pg3_t232? When I first saw ne3pg3_ne3pg3_t232 I thought it was a typo and was suppose to be ne3pg3_ne3pg3_mt232. Then I got confused when I saw that it was for a B compset test.

Very good point, @fischer-ncar . @kdraeder and @alperaltuntas can you please comment on this?

[kdraeder]

I haven't seen a description of an alias naming convention for grids,
so I adapted that name from grid names that seemed most similar in modelgrid_aliases_nuopc.xml.
I don't know what the 'm' or 't' mean.
I'm happy to use whatever you all recommend, and shorter is better in test names.

[Sorry about the errant comment; too many related PRs]