Initial clean-up in preparation for merging to global-workflow

[aerorahul]

This PR:

• adds a README.md to describe the project and basic instructions on how to build the executables of this repository
• removes the individual makefile for each executable
• removes older modulefiles
• uses spack-stack installed modules on hera and orion (hercules will be added later)
• changes permissions on the source code to remove -x
• updates detect_machine.sh to allow building on compute nodes

The build was successful on Hera, Orion, and WCOSS2

To build:

git clone -b feature/prep_for_gfsv17 https://github.com/noaa-emc/emc_gfs_wafs
cd emc_gfs_wafs
./ush/build.sh

The executables will be built under install/bin

tree install/
install/
└── bin
    ├── wafs_blending_0p25.x
    ├── wafs_cnvgrib2.x
    ├── wafs_gcip.x
    ├── wafs_grib2_0p25.x
    └── wafs_makewafs.x

[YaliMao-NOAA]

Thank you @aerorahul
May I know whether it's a global-workflow standard that the executable files have to be under install/bin? It used be under exec.

[aerorahul]

Thank you @aerorahul May I know whether it's a global-workflow standard that the executable files have to be under install/bin? It used be under exec.

They will be linked under exec/ at the application level (in the GFS) to conform w/ EE2 standards.
At build and compile time, all component build artifacts are installed under a local install/

[YaliMao-NOAA]

I compiled WAFS packages using CMake, reran the same case and the outputs are bit-wise identical other than GCIP which depends on accumulative METAR/SHIP/LIGHTNING observation bufr data.

[aerorahul]

I compiled WAFS packages using CMake, reran the same case and the outputs are bit-wise identical other than GCIP which depends on accumulative METAR/SHIP/LIGHTNING observation bufr data.

Thanks for the confirmation @YaliMao-NOAA