Update to crtm 3.1.5, GEOS templates, geos-gcm-env

[mathomp4]

Description

Main change: consolidate the dev templates on a single CRTM version, crtm@3.1.5.

• unified-dev: global-workflow-env, gsi-env, ufs-srw-app-env, ufs-weather-model-env move from crtm@3.1.3 to 3.1.5; gmao-swell-env moves from crtm@v2.4.1-jedi.2 to 3.1.5. The extra standalone crtm specs are removed. It builds only geos-gcm-env@11.10.0 (not 12.1.0), to avoid building geos-gcm-env twice.
• skylab-dev: one crtm@3.1.5; the 'list all tags to avoid duplicates' comment is removed since there is only one.
• nco: crtm@=3.1.2 -> 3.1.5; drop the upp ^crtm@=2.4.0.1 pin, so UPP uses CRTM 3.1.5 (needs checking); delete the template's envrepo crtm override, which shadowed the builtin recipe and lacked 3.1.3/3.1.5.

Other changes:

• geos_gcm_env: add 12.1.0 (11.10.0 preferred) and fms/cdo/grads variants with their dependencies
• geos-dev: geos-gcm-env 11.10.0 and 12.1.0 with +cdo +fms; add fms 2026.01.01; require one CDO build (+fftw3 grib2=eccodes)
• geos-dev-nag: ~fms ~cdo (NAG cannot build FMS yet due to cray pointers)
• New geos-dev-flang template
• Remove obsolete NAS gcc-14.2.0 and macOS clang-22.1.3/gcc-15.2.0 site configs
• jedi_base_env: remove commented-out line

Dependencies

None.

Issues addressed

None.

Applications affected

GEOS-GCM, GMAO SWELL, GSI, UFS WM, UFS SRW, global-workflow, JEDI/skylab (via the CRTM version change), NCO (UPP).

Systems affected

Template/recipe changes affect all systems using these templates. Removed site configs only affect NAS (gcc-14.2.0) and GMAO macOS (clang-22.1.3, gcc-15.2.0), which are obsolete.

Testing

• CI:
  • GitHub actions CI tests pass
  • GitHub actions CI tests do not pass (provide explanation)
  • GitHub actions CI tests skipped (commits use [skip ci]; changes are templates and GMAO-specific recipes)
• New tests added:
  • None
• Additional testing:
  • Not yet tested: nco (UPP against CRTM 3.1.5) and unified-dev concretization with the single CRTM

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[mathomp4]

Note: I added my geos-dev templates here. No one but me builds them, but I didn't put them in #2169 since I didn't want to trigger CI there prematurely.

[climbfuji]

@AlexanderRichert-NOAA Is it ok to remove the custom envrepo and crtm package, or shall we just not touch the nco template and envrepo when we update crtm to 3.1.5 elsewhere?

[mathomp4]

oh. I had my LLM (try to) be verbose in a comment below.

[mathomp4]

@AlexanderRichert-NOAA, a heads-up on the nco template changes in this PR, since I believe the NCO setup came from #1821 and you'd know best whether they are safe.

What changed in configs/templates/nco/

1. crtm@=3.1.2 -> crtm@=3.1.5 in spack.yaml.
2. upp ^crtm@=2.4.0.1 -> plain upp, so UPP now uses the single CRTM in the environment (3.1.5). I have not checked that UPP builds against CRTM 3.x; the old pin may have existed for API reasons.
3. Removed the whole envrepo/ directory (repo.yaml, packages/crtm/package.py, and v3.1.0-skylabv8.installprefix.patch).

Why the envrepo was removed

• stack_env.py copies a template's envrepo into envs/<env>/envrepo and adds repos: [$env/envrepo], so that copy of crtm shadows the builtin one.
• Compared with the builtin crtm recipe, it adds the old 2.3.0 version (with its crtm-fix@2.3.0_emc dependency, and ecbuild/netcdf-fortran for @v2.3). It lacks 3.1.3 and 3.1.5, their crtm-fix@3.1.2 dependency, the cmake@3.20: dependency, the link_fixed_files step, and the builtin check and oneapi conflicts.
• With the override in place, crtm@=3.1.5 could not concretize, because the shadowing recipe has no such version.
• Nothing left in the template uses crtm@2.3.0, so the override looked like a leftover.
• An envrepo containing only repo.yaml and no packages might be rejected, so I removed the whole directory. The copy step is guarded by isdir.

Not tested yet: concretizing the nco template, and building UPP against CRTM 3.1.5.

If NCO still needs CRTM 2.3.0, or UPP needs 2.4.0.1, the envrepo can be restored from git history (in that case it should also get the 3.1.3/3.1.5 versions so it doesn't shadow them). Please let us know.

[climbfuji]

Should we add this last minute?

[mathomp4]

I had to make those variants because NAG can't build either of those. So in my geos-dev-nag template I can turn them off.

Everyone else uses the default +cdo +fms and always had, but if I wanted to build a stack for nag, I needed a way to not build those bits.

I suppose in unified-dev I don't need to be as explicit as I am here:

  - geos-gcm-env@11.10.0 ~debug +cdo +fms ^esmf@=9.0.0b18

I could remove all three of those variants I suppose since they are just the defaults

[AlexanderRichert-NOAA]

Thanks-- I'll deal with the NCO template as needed. It doesn't really need to be in step with spack-stack releases so I can live with it being temporarily broken.

[mathomp4]

Looks like all might pass once the ifx version in ci updates.

[climbfuji]

We need one more approval here, and then it's down to one last PR before cutting the release branch (#2166).