Expanding regression tests to offer more gnu compiler coverage

[glemieux]

Given the recent minor issue #937, I'm wondering if we should add more regression tests that use the gnu compiler. While cheyenne and compy have access to the intel compiler, the gnu compiler is the default for perlmutter which is taking over when cori retires next year (perlmutter does not have access to intel). Currently @rgknox and I only have access to perlmutter as an officially supported e3sm machine.

The followup to this question is if we do add more tests, should we add them to the ctsm test suite or flesh out the e3sm test suite?

[glemieux]

Per the zoom call discussion wit @rgknox we agreed on the following tasks:

1. short term: add gnu reduced complexity more test to cheyenne
2. near term: audit of e3sm-land-developer test to gain more coverage

We both agreed that adding more fates specific tests (threading, exact restarts, reduced complexity) to the e3sm land developer regression test suite will help us gain more coverage on the e3sm side given that other elm updates outside of fates will exercise this (similar to the aux_clm test suite on the ctsm side).

There was a question as to whether or not the land developer tests will be run on perlmutter and if they are compiler agnostic.

[glemieux]

Another thought while I was reviewing regression tests this morning. We should probably run an audit of the history variables that are including/excluded from the namelist updates for the testbeds. In particular, I'm wondering if its ok to have a very limited set for specific run modes if the test suite is running with at least some expanded history outputs. For example, the mortality test mod has a pretty small subset of mortality variables, but the rest of the test setup (compost, duration, etc) has a decent amount of overlap with testmods that have more history output.