Update the gdas.cd hash and enable GDASApp to run on WCOSS2

[RussTreadon-NOAA]

Description

This PR does the following:

1. update the sorc/gdas.cd hash to bring new GDASApp functionality into g-w
2. update env/WCOSS2.env
3. update the WCOSS2 section of ush/module-setup.sh

The change to WCOSS2.env is due to changes introduced during the fall 2024 WCOSS2 upgrade. The change to module-setup.sh is required when using spack-stack on WCOSS2.

Resolves #3219
Resolves #3100

Type of change

• Maintenance (update gdas.cd hash)

Change characteristics

• Is this a breaking change (a change in existing functionality)? NO
• Does this change require a documentation update? NO
• Does this change require an update to any of the following submodules? YES
  • GDAS - this PR points at the updated sorc/gdas.cd hash. No PRs are pending.

How has this been tested?

• Clone and build on WCOSS2, Hera, Hercules, and Orion
• Run g-w CI on WCOSS2, Hera, Hercules, and Orion

Checklist

• Any dependent changes have been merged and published
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• New and existing tests pass with my changes

[RussTreadon-NOAA]

This PR is opened in draft mode until g-w CI has been run on WCOSS2, Hera, Hercules, and Orion.

The g-w team is invited to review and comment on changes to env/WCOSS2.env and ush/module-setup.sh. The changes in env/WCOSS2.env originate from the discussion in WCOSS Ticket#2024111410000051.

[aerorahul]

No issues here with the hash update.
I am not sure we are cleared to use spack-stack on WCOSS2 for regular development. The installed stack was for demonstration and testing purposes for NCO staff.

[aerorahul]

This is fine for now, but will not be acceptable for implementation. I hope there is a more robust solution than this by that time.

More importantly, this has an impact on every executable in every job -- not just GDASApp executables.

[RussTreadon-NOAA]

I completely agree. I strongly dislike these two lines. They are temporary patches to allow GFS v17 testing and development to continue on WCOSS2.

The line

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOMEgfs}/sorc/gdas.cd/build/lib"

was added because craype/2.7.17 adds

-static-libgcc -static-libstdc++ -Bstatic -lstdc++ -Bdynamic -lm -lpthread

to the ftn command. GDASApp executables failed because they could not find JEDI libraries. Might the addition of a GDASApp install option (something we must have) resolve this problem?

Another concern with the added ftn options is the following warning found in build_gdas.log

icpc: warning #10315: specifying -lm before files may supersede the Intel(R) math library and affect performance
ifort: warning #10315: specifying -lm before files may supersede the Intel(R) math library and affect performance

It would be unfortunate if default compiler options resulted in degraded code performance.

The line

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/opt/cray/pe/mpich/8.1.19/ofi/intel/19.0/lib"

was recommended by GDIT. GDASApp testing identified inconsistencies in across system modules. Some GDASApp executables failed with undefined symbol messages for mpi routines. GDIT is working on a solution.