EAMxx:Adds a fully coupled compset with EAMxx

[singhbalwinder]

A fully coupled test with ne4 grid is added that uses EAMxx as its atmosphere model.

[ndkeen]

This is obviously a huge step forward over no testing of config.
It might be that DEBUG is more trouble than it's worth on GPU's.

I agree with others that ERS might be better than SMS, but when I tried I also get the issue with archiving.

I might suggest we also include ne30 coupled test ne30pg2_EC30to60E2r2.WCYCLXX2010

Ideally, we could have DEBUG ne4 run on CPU, and OPT ne30 on GPU.

Another detail is that coupled cases will fail to build using the default AMD compiler on frontier, so I've been testing with Cray compiler.

I just don't want to delay getting some sort of test in

[mahf708]

i agree with ndk, how about we do the following:

• SMS_D ne4
• ERS ne4
• SMS ne30

[ndkeen]

The ERS test fails with archiving error

[rljacob]

The archive problem is probably because there's no eamxx entry in config_archive.xml. Its just "scream". There's needs to be a general scream->eamxx switch in the xml files and compset long names.

[singhbalwinder]

Thanks all. Previously we talked about pruning the number of tests we run in the nightlies. @bartgol : Would it be okay if we add three new tests in the nightlies?

[singhbalwinder]

Maybe we should add one simple test first so that we at least have the testing in place for this compset. We can add more if desired in another PR.

[mahf708]

Thanks all. Previously we talked about pruning the number of tests we run in the nightlies. @bartgol : Would it be okay if we add three new tests in the nightlies?

I don't think we ever wanted to reduce the number of nightly tests. The discussion we had was about testing on CI resources/containers.

[ndkeen]

I would change this to not be a DEBUG test. That is remove _D.
And obviously no need for Ln5 at ne4.
And, I would just use ne30.

[tcclevenger]

@singhbalwinder is this ready?

[bartgol]

The archive problem is probably because there's no eamxx entry in config_archive.xml. Its just "scream". There's needs to be a general scream->eamxx switch in the xml files and compset long names.

While it's true that we need to change that, in config_component.xml we still have scream as name. Also, we do run plenty of ERS tests for eamxx (nightly as well as CI); why do they work everywhere else?

[singhbalwinder]

I tried, but the archive fails even if I add an eamxx entry in config_archive.xml. There are several eamxx/scream mismatches, and I am trying to fix those. This PR is not ready yet.

[mahf708]

@singhbalwinder you're not outputting anything here, so there's no archiving to do in eamxx. The archive snippet there works (but only if your output files have the string ".h." in them somewhere. Unlike other components, eamxx doesn't have any default output set.

[mahf708]

I was just talking to @singhbalwinder: I think we should change the coupled compset, it is not necessarily consistent with SCREAMv1 compset currently:

  <alias>WCYCLXX2010</alias>
- <lname>2010_EAMXX_ELM%SPBC_MPASSI_MPASO_MOSART_SGLC_SWAV</lname>
+ <lname>2010_SCREAM_ELM%SPBC_MPASSI_MPASO_MOSART_SGLC_SWAV</lname>

Note how SCREAMv1 is defined:

      <alias>F2010-SCREAMv1</alias> <!-- Coupled land-atm compset (using SCREAMv1), 2010 initial conditions -->
      <lname>2010_SCREAM_ELM%SPBC_CICE%PRES_DOCN%DOM_SROF_SGLC_SWAV_SIAC_SESP</lname>

Then, when we should change all compsets at once from SCREAM to EAMXX

[singhbalwinder]

Thanks, Naser! This fixes the short term archiving issue. This PR is now ready to merge.

[ndkeen]

Would that change only impact things like archiving? We don't expect it to change behavior otherwise?

[singhbalwinder]

Would that change only impact things like archiving? We don't expect it to change behavior otherwise?

Yes, it should not change anything else. The lines for _EAMXX and _SCREAM are identical (see here)