Describe the bug
Using build_stack.sh fails to install hpc-stack-nco in ubuntu 20.04 container

To Reproduce

1. (terminal 1) git clone --branch feature/hpc-stack-nco https://github.com/NOAA-EMC/hpc-stack
2. (terminal 2) docker run --rm -it --name hpc-container noaaemc/ubuntu-base:v1
3. (terminal 1) cd hpc-stack
4. (terminal 1) docker cp . hpc-container:/home/builder/hpc-stack
5. (terminal 2) cd hpc-stack
6. (terminal 2) export HPC_MPI=mpich/3.3.2 &&
   ./build_stack.sh -p /home/builder/opt -c config/config_custom.sh -y config/stack_custom.yaml

Build fails with "[[: not found" error message.

Change all lib/build_*.sh from #!/bin/sh to #!/bin/bash

Repeat above steps and build fails with:

-- Could NOT find NetCDF_Fortran (missing: NetCDF_Fortran_LIBRARY NetCDF_Fortran_INCLUDE_DIR)
CMake Error at src/flib/CMakeLists.txt:275 (message):
Must have PnetCDF and/or NetCDF Fortran libraries
-- Configuring incomplete, errors occurred!
See also "/home/builder/hpc-stack/pkg/pio-2.5.1/build/CMakeFiles/CMakeOutput.log".
BUILD FAIL! Lib: pio Error:1

System:
Ubuntu 20.04, gcc 9, mpich 3.3.2

As this is going to be (along with NCEPLIBS) one of the two projects that exterior users are pointed at, we want to have some standard questions in the issue which can be set up with a github template. I've done this for NCEPLIBS.

I will put up a PR with some questions. @aerorahul @kgerheiser @DusanJovic-NOAA and others: what questions should be asked?

Here's what I have for NCEPLIBS bug reports:

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
Steps to reproduce the behavior:

**Expected behavior**
A clear and concise description of what you expected to happen.

**Build Information**
How did you build or access NCEPLIBS?

**System**
On what system are you running the code?

**Additional context**
Add any other context about the problem here.

Here's what I have for feature requests:

**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. 

**Describe the solution you'd like**
A clear and concise description of what you want to happen.

**Resources and Schedule**
Who is expected to do the work, and what is the schedule?

Describe the bug
The udunits CI test on macOS is failing.

To Reproduce
Create a branch and push. This will trigger the CI.
Watch it fail.

Expected behavior
The test should have passed.

System:
Have not experienced this bug on any of the systems we are currently running on.

Additional context
Issue has been opened with udunits at Unidata/UDUNITS-2#97

We need to install the version of the hpc-stack in branch feature/hpc-stack-nco on Cheyenne (so that we get upp and not nceppost) for the ufs-weather-model.

The develop branch of hpc-stack has received updates (#38) for compiling on Cheyenne, with several bugfixes and improvements to use static libraries and compile/look for libjpeg etc. These updates are not in feature/hpc-stack-nco. PR #62 fixes this.

Add CDO module for application of porting global-workflow wave-prep job to hpc-stack for GFSv16 application.

Describe the solution you'd like
For operations we are using cdo/1.9.8 and CDO_ROOT needs to be defined as part of the module

Additional context
For this specific application, only netcdf features are needed.

ESMF team has updated esmf to esmf810bs36, we need this library to be built in hpc stack in both regular and debug mode to test the new features in this esmf version. We need the lib on hera/orion/dell

Is your feature request related to a problem? Please describe.
Containers and container specific files will be moved out of this repository and placed in emc-containers
This will allow better organization and testing for containers as their use and need continue to grow at EMC.

Describe the solution you'd like
Move container related files to their own repo.

Is your feature request related to a problem? Please describe.
Currently setup_modules.sh does not check if the meta modulefiles for compiler and mpi as well as for the stack are present or not.

Describe the solution you'd like

Add a layer of security that warns the user that modulefiles for the compiler and MPI are already present and queries the user if they want to over-write them. In most (almost all), the answer is NO, since these just load the underlying compiler module file or use the system compiler/MPI.

Github (and the wider community) are moving away from the master branch name to main.
This is in accordance with this Github repo.

Since the master branch in this repo is a name-only, the impact is minimal.

Describe the solution you'd like
Follow advice in the link above.

The more stack files that are added the more tedious it becomes to maintain nearly identical files and the more chance for errors.

What ones do we really need and what ones we can get rid of or combine, if any:

stack_mac.yaml: Builds MPI by default, disables OpenMP on certain libraries because Clang doesn't have it, builds shared libraries

stack_custom.yaml: This is the default config is no other is specified, builds shared libraries

stack_gaea.yaml: For Gaea, disables building a bunch of libraries, build static libs

stack_ncar.yaml: The only difference from stack_noaa.yaml is that it doesn't build json and json_schema_validator

stack_noaa.yaml: Doesn't contain options for gnu and MPI, compared to stack_custom.yaml, builds static libraries

stack_ufs_weather_ci.yaml: Disables building a bunch of libraries, builds shared libraries

See NOAA-EMC/NCEPLIBS#130.

We need CI for this project.

Is your feature request related to a problem? Please describe.

UFS weather model is not running Regression Tests on JET. We need that support as multiple research communities depend on it.

Describe the solution you'd like

We need hpc-stack installed on JET so that a compatible UFS weather model build support is available

Additional context

This is a critical need so please elevate as much as possible

Is your feature request related to a problem? Please describe.
On hpc-stack on Hera, in module jasper, png and z, I can't find environment variables defined as JASPER_LIB, PNG_LIB, Z_LIB. These environment variables are required in current UPP GNC build makefile.

Describe the solution you'd like
Would these environment variables be added or you made the changes in hpc-stack on purpose?

Additional context
Add any other context or screenshots about the feature request here.

I installed hpc-stack on stampede2 and attempted to use it in place of NCEPLIBS-develop in my successful build of prototype5.0. It failed with the following:

mpiifort -o /work/02441/bcash/stampede2/s2s_p5_port/NEMS/exe/NEMS.x MAIN_NEMS.o module_NEMS_UTILS.o module_MEDIATOR_methods.o module_MEDIATOR.o module_MEDIATOR_SpaceWeather.o module_EARTH_INTERNAL_STATE.o module_EARTH_GRID_COMP.o module_NEMS_INTERNAL_STATE.o module_NEMS_GRID_COMP.o module_NEMS_Rusage.o nems_c_rusage.o /work/02441/bcash/stampede2/s2s_p5_port/CMEPS_INSTALL/libcmeps.a /work/02441/bcash/stampede2/s2s_p5_port/CMEPS_INSTALL/libcmeps_util.a /work/02441/bcash/stampede2/s2s_p5_port/CMEPS_INSTALL/libpiof.a /work/02441/bcash/stampede2/s2s_p5_port/CMEPS_INSTALL/libpioc.a /work/02441/bcash/stampede2/s2s_p5_port/WW3/model/obj_HYB/libww3_multi_esmf.a /work/02441/bcash/stampede2/s2s_p5_port/CICE-interface/CICE_INSTALL/libcice6.a /work/02441/bcash/stampede2/s2s_p5_port/MOM6-interface/MOM6_INSTALL/libmom.a /work/02441/bcash/stampede2/s2s_p5_port/MOM6-interface/MOM6_INSTALL/lib_ocean.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libfv3cap.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libccppdriver.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libfv3core.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libfv3io.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libipd.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libgfsphys.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libfv3cpl.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libstochastic_physics_wrapper.a /work/02441/bcash/stampede2/s2s_p5_port/FV3/FV3_INSTALL/libstochastic_physics.a /work/02441/bcash/stampede2/s2s_p5_port/FMS/FMS_INSTALL/libfms.a -L/work/02441/bcash/stampede2/s2s_p5_port/FV3/ccpp/lib -lccpp -lccppphys ENS_Cpl/ENS_Cpl.a /work/02441/bcash/stampede2/intel-18.0.2/impi-18.0.2/nemsio/2.5.2/lib/libnemsio.a /work/02441/bcash/stampede2/intel-18.0.2/bacio/2.4.1/lib/libbacio_4.a /work/02441/bcash/stampede2/intel-18.0.2/sp/2.3.3/lib/libsp_d.a /work/02441/bcash/stampede2/intel-18.0.2/impi-18.0.2/w3emc/2.7.3/lib/libw3emc_d.a /work/02441/bcash/stampede2/intel-18.0.2/w3nco/2.4.1/lib/libw3nco_d.a -L/work/02441/bcash/stampede2/intel-18.0.2/impi-18.0.2/esmf/8_1_0_beta_snapshot_27/lib -Wl,-rpath,/work/02441/bcash/stampede2/intel-18.0.2/impi-18.0.2/esmf/8_1_0_beta_snapshot_27/lib -lesmf -cxxlib -lrt -ldl -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz -ldl -lm -qopenmp -L/work/02441/bcash/stampede2/intel-18.0.2/impi-18.0.2/netcdf/4.7.4/lib -lnetcdff -lnetcdf -L -lpnetcdf
/opt/apps/gcc/6.3.0/bin/ld: cannot find -lhdf5_hl
/opt/apps/gcc/6.3.0/bin/ld: cannot find -lhdf5
gmake[1]: *** [nems] Error 1

The README can be updated. See NOAA-EMC/NCEPLIBS#120

Looks like we need a versioned release of hpc-stack.

I am looking at the netCDF install script and I have some questions.

1 - You install netcdf-cxx? Does anyone use that? It is very lightly maintained...
2 - You use --enable-pnetcdf? That surprises me too. Is anyone at NOAA using this feature (i.e. parallel I/O with classic format files with the pnetcdf layer).
3 - You use --enable-cdf5. This is not necessary since version 4.7.? as it is now enabled by default.
4 - --enable-netcdf-4 is on by default so is not needed.
5 - --disable-doxygen is already the default so not needed.
6 - --disable-dap is a significant loss of functionality. Why is dap always disabled?
7 - When you run parallel tests with netcdf, it uses mpiexec to launch jobs. That works on all NOAA machines?

In the develop branch there's ESMF bs27, while in the branch feature/nco bs36 is being used.

Should we update?

The grib_util.lua file need to add " " to the last column.

https://github.com/NOAA-EMC/hpc-stack/blob/develop/modulefiles/compiler/compilerName/compilerVersion/grib_util/grib_util.lua

setenv("CNVGRIB", pathJoin(base, "bin", cnvgrib))
setenv("COPYGB", pathJoin(base, "bin", copygb))
setenv("COPYGB2", pathJoin(base, "bin", copygb2))
setenv("DEGRIB2", pathJoin(base, "bin", degrib2))
setenv("GRB2INDEX", pathJoin(base, "bin", grb2index))
setenv("GRBINDEX", pathJoin(base, "bin", grbindex))
setenv("GRIB2GRIB", pathJoin(base, "bin", grib2grib))
setenv("TOCGRIB", pathJoin(base, "bin", tocgrib))
setenv("TOCGRIB2", pathJoin(base, "bin", tocgrib2))
setenv("TOCGRIB2SUPER", pathJoin(base, "bin", tocgrib2super))
setenv("WGRIB", pathJoin(base, "bin", wgrib))

Some suggested process improvements from @arunchawla-NOAA

The issues section is being used well so I am glad about that. A few points

1. On the issues page of hpc-stack if someone is working on an issue please assign to them so we know who is handling what.

2. On our wiki page we do not identify where test versions are located. When we are adding to test versions we should identify in the wiki (or in the issues page)

3. The management of hpc-stack was identified on a google document but has not made it to the wiki yet. Can we do that? Then everyone will know the process of updating stacks on different platforms

4. There are good labels on the issues sections but they are not being used yet. Can we add those ?

Turn on branch protections for develop branch. See NOAA-EMC/NCEPLIBS#154

After we merge the changes from feature/hpc-stack-nco, we will delete this branch and we will not create another like it.

Feature branches will be short-lived, apply to specific issue or issues, and be rapidly merged back into develop.

No one on any other team should ever be using or installing anything other than the official hpc-stack releases. If test builds are made, of develop or of a feature branch, they are only for testing and never for any operational use.

Cheyenne has a default (OS) shared library libjpeg.so in /usr/lib64/, but on the login nodes only. While the stack can be built, running the ufs-weather-model on the compute node then fails with a shared library load error.

When trying to fix this, I found that
(a) libjpeg is always built dynamically, regardless of the SHARED entry in the YAML stack config file
(b) when libjpeg is built by hpc-stack, it is ignored if another version is found (for example in the standard search paths); I assume that the build would fail if there was not libjpeg in the standard search paths

As per NOAA-EMC policy (I cannot find a link to that policy), only the main branches will be available on this repository.
Users are encouraged to fork the repository to create local branches and issue a PR when ready.

This repository will become read-only to the public and all PR's will need approvals.

The following branches will be removed on Nov 30, 2020 ; owners please take note and sync.

From George's email:

I've often stated we need to standardize across NOAA what our modules actually set. One example is the netcdf module which sometimes sets $NCETCF or $NETCDF_ROOT or $NETCDF-DIR and sometimes $NETCDF_LIB and $NETCDF_INCLUDE.
It also needs to set LD_LIBRARY_PATH to find shared libraries at runtime. (I was slow to pick up on this because I try to build everything static wherever possible and modify build systems to do the static links)

When I use netcdf in my modules I set $NETCDF and then specify $NETCDF_LIB as $NETCDF/lib in the build system and (a recent improvement) use $NETCDF/bin/nc-config --libs to specify the libraries needed in the build system, NOT in the module

A self configuring build system may require a few other variables I (rather primitive if you look closely at my work) don't yet incorporate, for example nc-config which I started using this year.

So for starters the netcdf module needs to set
$NCETCDF_ROOT (i think we agreed on this base name)
and prepend $NETCDF_ROOT/lib to $LD_LIBRARY_PATH

. I would put $NETCDF_ROOT/bin, $NETCDF_ROOT/include and $NETCDF_ROOT/lib in a build system rather than expecting a module to set them.

Anything I am missing (likely yes. please consider) . And am I being unreasonable to expect a build system to set the derivative stuff from $NETCDF_ROOT.

I am trying to build ufs-weather-model on WCOSS2. I built hpc-stack witl all third party dependencies on
/lfs/h2/emc/nceplibs/noscrub/gwv/hpcstack/install
and then ran the following fv3 module

module unload cpe-cray cce
module load cpe-intel intel
setenv CMAKE_C_COMPILER cc
setenv CMAKE_CXX_COMPILER CC
setenv CMAKE_Fortran_COMPILER ftn
setenv CMAKE_Platform wcoss2

module use /lfs/h2/emc/nceplibs/noscrub/gwv/hpcstack/install/modulefiles/stack
module load hpc/1.0.0-beta1
module load hpc-intel/19.1.1.217
module load hpc-cray-mpich/8.0.15

module load jasper/2.0.16
module load zlib/1.2.11
module load png/1.6.35

module load hdf5/1.10.6
module load netcdf/4.7.4
module load pio/2.5.1
module load esmf/8.1.0.beta_snapshot_26

module load bacio/2.4.1
module load crtm/2.3.0
module load g2/3.4.1
module load g2tmpl/1.9.1
module load ip/3.3.3
#module load nceppost/dceca26
module load nemsio/2.5.2
module load sp/2.3.3
module load w3emc/2.7.3
module load w3nco/2.4.1

The build fails immediately in cmake with

cmake /lfs/h1/ptmp/gwv/u/ufs-weather-model -DNETCDF_DIR=/lfs/h2/emc/nceplibs/noscrub/gwv/hpcstack/install/intel/19.1.1.217/cray-mpich/8.0.15/netcdf/4.7.4

Setting configuration for wcoss2

32BIT ............ OFF
AVX2 ............. ON
SIMDMULTIARCH ... OFF
CCPP ............. ON
DEBUG ............ OFF
DEBUG_LINKMPI .... OFF
INLINE_POST ...... ON
MULTI_GASES ...... OFF
OPENMP ........... ON
PARALLEL_NETCDF .. ON
QUAD_PRECISION ... ON
REPRO ............ OFF
WW3 .............. OFF
S2S .............. OFF
DATM ............. OFF

C compiler: Intel 19.1.0.20200306 (icc)
CXX compiler: Intel 19.1.0.20200306 (icpc)
Fortran compiler: Intel 19.1.0.20200306 (ifort)

-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES MPI_CXX_HEADER_DIR MPI_CXX_WORKS)
-- Could NOT find MPI_Fortran (missing: MPI_Fortran_LIB_NAMES MPI_Fortran_F77_HEADER_DIR MPI_Fortran_MODULE_DIR MPI_Fortran_WORKS)
CMake Error at /apps/spack/cmake/3.16.5/intel/19.1.1.217/bpo6rqfb7df7brzqtbodvcegzjgmyf5u/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND MPI_Fortran_FOUND)
Call Stack (most recent call first):
/apps/spack/cmake/3.16.5/intel/19.1.1.217/bpo6rqfb7df7brzqtbodvcegzjgmyf5u/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/apps/spack/cmake/3.16.5/intel/19.1.1.217/bpo6rqfb7df7brzqtbodvcegzjgmyf5u/share/cmake-3.16/Modules/FindMPI.cmake:1700 (find_package_handle_standard_args)
CMakeLists.txt:90 (find_package)

-- Configuring incomplete, errors occurred!
See also "/lfs/h1/ptmp/gwv/u/ufs-weather-model/build/CMakeFiles/CMakeOutput.log".
See also "/lfs/h1/ptmp/gwv/u/ufs-weather-model/build/CMakeFiles/CMakeError.log".

What is wrong? I find it alarming that I can't build ufs-weather model using hpc-stack on WCOSS2. I was able to build the previous generation, fv3gfs using the make based build and hand built NCEPLIBS and third party libraries.

Has anybody tried to build ufs-weather model on WCOSS2 using a lmod based hpc-stack

I built hpc-stack as follows

source /apps/prod/lmodules/startLmod
export P=/tmp/hpcstack
export P=/lfs/h2/emc/nceplibs/noscrub/gwv/hpcstack/install
./setup_modules.sh -p $P -c config/config_wcoss2.sh
./build_stack.sh -p $P -c config/config_wcoss2.sh -y config/stack_noaa.yaml -m

When I removed the -m to try a flat build, the build failed to find the netcdf it had just built so I punted there.

It's important we get this nailed down and I am for the moment making painfully slow progress. I do not
want to revert back to a make based ufs build to get the thing to somehow build in a way that won't be portable
moving forward.

It's possible this is a cmake build issue in UFS. I don't know.

I know Mark Potts is close or has done it with a flat (non lmod modules) implementation of hpc-stack

Not sure if this is a bug or intended.

I installed hpc-stack for the GNU compiler on cheyenne in

/glade/p/ral/jntp/GMTB/tools/hpc-stack-20201022

This creates the following directories underneath:

core
gnu-9.1.0
modulefiles
src # this one is mine

In a second step, I tried to install hpc-stack for the Intel compiler in the same directory structure, which then adds

intel-19.1.1

as expected. ./build_stack.sh however fails with the error

+ echo 'WARNING: /glade/p/ral/jntp/GMTB/tools/hpc-stack-20201022/core/eigen/3.3.7 EXISTS, SKIPPING'
WARNING: /glade/p/ral/jntp/GMTB/tools/hpc-stack-20201022/core/eigen/3.3.7 EXISTS, SKIPPING
+ exit 1
BUILD FAIL!  Lib: eigen Error:1

Obviously the intel stack is trying to install the (compiler-independent because using native gnu?) eigen library again.

Is this intended? I would have thought that hpc-stack should either overwrite automatically or ignore building shared libraries in the core directory that are independent of the compiler and mpi library.

We are doing the hpc-stack-1.1.0 release in the near future. @GeorgeVandenberghe-NOAA has tagged a release in UFS_UTILS. Shouldn't we be using it?

cron jobs can test hpc-stack and email the results.

wgrib2 should be built with USE_IPOLATES to enable re-gridding within wgrib2

See: #75 (comment)

It was disabled (and also broken for other reasons) because it creates extra dependencies in the library part of wgrib2. It has since been fixed with the latest wgrib2 release which builds a simple library, so we can re-enable this feature again.

I will fix this with #76

When I look on the releases page I see one release, v1.0.0-beta1.

Isn't hpc-stack already in use? In which case, we should have an actual 1.0.0 release, instead of just a beta. ;-)

Wen has added the nceppost with UPP version of 10.0.0. She request the installation test through hpc-stack.
We will first try it from the EMC_POST/develop branch, on each machine.
If it is okay, she needs to create a release to formally included in the hpc-stack.

A branch has been created to this issue
feature/postupdate

There is a new prod_util release due to issue #71
We need to update hpc_stack to the new release.

There have been changes to NCEPLIBS-bufr. They have not yet been released - but I believe they are from the public-v2 branch.

Are these changes necessary for hpc-stack-1.1.0? @jbathegit ?

Clearly identify, who officially maintains a stack on which machine.
There can be a back-up.

Establish a process for updating a stack and the versioning that goes with it:

• Is the update in a single package which has no downstream dependency in the stack e.g. ESMF
• is the update in a single package which has downstream dependencies e.g. hdf5 or netcdf
• Is the update to the stack due to change in the Compiler + MPI combination?

And more.

The current versions of MPICH, ESMF, UPP, and grib_util do not build with GCC 10 due to argument mismatch.

Passing the flag -fallow-argument-mismatch fixes the problem for ESMF and MPICH (through ESMF_F90COMPILEOPTS and FCFLAGS)

Tags need to be updated for UPP and grib_util (fix present in develop branch)

Right now we have two ESMF snapshot releases we have to support, and to do that we have to install the stack, then turn everything else off, change the ESMF version, and install again.

Well that's not great.

Furthermore, it looks like this will be happening frequently, as mentioned in #41

So how can we best handle multiple ESMF installs?

How can we best handle rapidly adding a new ESMF version? Do we do a release of hpc-stack each time?

Describe the bug
The UPP standalone test for GFS V16 failed with pro_util/1.2.1 as:

0.008 + export cycle
0.008 + setpdy.sh
/scratch2/NCEPDEV/nwprod/hpc-stack/test/intel-18.0.5.274/prod_util/1.2.1/bin/setpdy.sh: line 46: COMROOT: parameter null or not set
0.013 + . ./PDY
/scratch1/NCEPDEV/stmp2/Wen.Meng/upp_stack/EMC_post/jobs/J_NCEPPOST[58]: .: ./PDY: cannot open [No such file or directory]

It is no problen if I load prod_util/1.1.0 from /scratch2/NCEPDEV/nwprod/NCEPLIBS/modulefile.

NCO requires us to do following changes on hpc-stack to meet their first implementation requirements.

1. Building only nceplibs libraries, and with their machine installed thrid party libraries.
2. change the installation folder intel-version into intel/version.

I have prepared a testing version on this for them to do initial test now.
and will push it to a feature branch in the repo for all to review soon.
They said that they may have more requirements upon testing.

After the PR today I noticed the UPP update is missing from these files.

Are these oversights? Should they be added?

NOAA PSL is exploring the use of hpc-stack to enable UFS on AWS with the use of Docker and Singularity containers
In associated PR's, Docker Doxyfiles for Intel using Intel OneAPI will be added/contributed.
Thanks to @slawrence87544

On the other repos we have identified a code manager.

Who is the code manager or managers for this hpc-stack repo? Is there a consensus on who this should be?

The code manager will take primary responsibility for monitoring and prioritizing issues, reviewing and merging PRs, and planning and executing releases.

Current version of grib_util does not build with GCC 10

v1.2.2 fixes this problem

I am working with NCO to get MET (https://github.com/dtcenter/MET) version 9.1.0 into operations. It was discovered when compiling MET with g2c/1.5.0 on both the Dell and Cray lead to a problem to arise. When MET is compiled with g2c/1.6.0, the problem goes away. I am requesting for g2c/1.6.0 to be installed on all WCOSS machines.

wgrib2's build had a bug that caused compile definitions to not be passed correctly and resulted in broken features

Update wgrib2 to the latest release

I will need to install hpc-stack on gaea.

All modules generated by hpc-stack are lua modules, which gaea doesn't understand. gaea knows tcl modules, and so does every other system.

What is the strategy for supporting gaea (after all, it is a NOAA RDHPC system)?

The quick-and-dirty lua2tcl.py script I added to NCEPLIBS won't work out of the box for the hpc-stack modules I guess, and it's really only duct tape instead of doing it right.

See discussion in #83.

Update Jasper to use version 2.0.22 which includes a fix for this (and other security issues)

Fanglin, Jun and Kate send requests to have hpc-stack provide GFSv16 operational standard libraries.

This include match all libraries that NCEPLIBS group sent to NCO and used in GFSv16 associated component development.
LIst of major modules asked to change include: netcdf/hdf5, UPP.
Asked to match all other used library modules.
Install the testing versions on all NOAA platforms.
Testing standard: reproduce the GFSv16 testing results.

As discussed in #83, we will add a section to the readme with the installers on different machines.