Allow reading and processing large grib2 files in chgres_cube, such as grib2 RRFSv1 output on native levels

[natalie-perlin]

DESCRIPTION OF CHANGES:

Allow reading and processing large grib2 files by chgres_cube , which otherwise produce errors when reading large grib2 files, such as RRFSv1 model output on native or pressure levels for the 3-km full-NA grid. Files retrieved from https://registry.opendata.aws/noaa-rrfs/, AWS S3 bucket
https://noaa-rrfs-pds.s3.amazonaws.com/index.html#rrfs_a/
naming conventions rrfs.t{HH}z.natlev.f{FHR}.grib2 and rrfs.t{HH}z.prslev.f{FHR}.grib2

TESTS CONDUCTED:

Run a test on Hera of reading rrfs.t00z.natlev.f000.grib2 file from a RRFSv1 control run for a date 2024110600, for the small test domain over California. Test runscript is as follows, placed under ./ush directory:
run_chgres_cube.sh.txt, with the following input file: fort.41.txt. Log files attached below in the Testing
A chgres_cube executable that reads a large grib2 file was successful, for the binary built with either Intel or GNU compilers, using updated spack-stack locations as in the PR #1028. The tests reported exit code=0.
Surface files were prepared by the UFS-SRW grid and orography tasks that do not yet employ fractional vegetation and soil data, and this was indicated in the end of the file, i.e.: i

 - OPEN FILE /scratch2/NCEPDEV/stmp1/Natalie.Perlin/SRW1/expt_dirs/test_RRFS_test/fix_lam/C10008.slope_type.tile7.nc
 - FILE CONTAINS            1  TIME RECORDS.
 - FATAL ERROR: Detected missing data point in /C10008.slope_type.tile7.nc. Static data may be outdated. Please use static data created with the latest UFS_UTILS release that supports fractional land coverage
 - IOSTAT IS:           -1

Finished running chgres_cube, from a script run_chgres_cube.sh
_______________________________________________________________
Start Epilog on node h32m03 for job 8002908 :: Tue Mar 11 21:51:52 UTC 2025
Job 8002908 finished for user Natalie.Perlin in partition bigmem with exit code 0:0
_______________________________________________________________
End Epilogue Tue Mar 11 21:51:52 UTC 2025

Log files:
log.cube.8002181.intel.txt
log.cube.8002908.gnu.txt

• Compile branch on all Tier 1 machines using Intel (Orion, Jet, Hera, Hercules, Gaea C5/C6 , but not WCOSS2).
  Build Log files:
  log.build.hera.intel_large_grib2.txt
  log.build.orion.intel_large_grib2.txt
  log.build.hercules.intel_large_grib2.log
  log.build.jet.intel_large_grib2.txt
  log.build.gaeac5.intel_large_grib2.txt
  log.build.gaeac6.intel_large_grib2.txt

• Compile branch on Hera using GNU.
  log.build.hera.gnu_large_grib2.txt

• Compile branch on NOAA Cloud Service providers: AWS, Azure, GCP.
  log.build.noaacloud.AWS.intel_large_grib2.txt
  log.build.noaacloud.Azure.intel_large_grib2.txt
  log.build.noaacloud.GCP.intel_large_grib2.txt

• Compile branch in 'Debug' mode on WCOSS2.

• Compile with Doxygen on any machine with no errors.

• Run unit tests locally on any Tier 1 machine.

• Run relevant consistency tests locally on all Tier 1 machines.

Optional test.

• Run full set of chgres_cube consistency tests on Hera.
• Run chgres_cube test on Hera with Intel and Gnu compilers, as indicated in description

DEPENDENCIES:

Add any links to pending PRs that are required prior to merging this PR. For example:

ufs-community/UFS_UTILS/pull/1028

DOCUMENTATION:

All new and updated source code must be documented with Doxygen.

• Doxygen is updated.

If this PR is contributing new capabilities that need to be documented, please also include updates to the RST files in the docs/source directory as supporting material.

ISSUE:

Fixes #850, #660 and ufs-community/ufs-srweather-app#1191

CONTRIBUTORS (optional):

@LarissaReames-NOAA

[GeorgeGayno-NOAA]

Will look at this after #1028 is merged.

[GeorgeGayno-NOAA]

Was zlib causing a problem or is it not used?

[natalie-perlin]

zlib was not used, apparently, and I would put it back into the module.

[GeorgeGayno-NOAA]

I removed the module load of zlib for the intelllvm build. Everything built fine. Apparently, zlib is automatically loaded from some other module. I only tried this test on Hera.

[GeorgeGayno-NOAA]

@natalie-perlin - the CI checks are failing because they use the previous version of g2. Can you update the spack.yaml file to use the newer g2?

Updating the ./ci/spack.yaml to have similar versions of packages as the modulefiles. In particular, these are updated:
g2/3.5.1
ip@4.3.0
sigio@2.3.2

There is no nco listed (nco/5.0.6) in the spack.yaml, but it is present in the modulefiles. If the build fails, I may add nco as well.

[GeorgeGayno-NOAA]

@natalie-perlin - not sure why your CI checks are breaking. As a test, I updated the spack.yaml file (in my fork) to use g2 3.5.1. Everything ran. Can you clean out your cache and restart the CI tests?

[natalie-perlin]

@GeorgeGayno-NOAA -
Not sure what I may need to do to help with the CI tests. I'll reach out to EPIC team members that are more experienced with the CI configuration/settings, and find out what needs to be done.

[GeorgeGayno-NOAA]

@natalie-perlin - what is the status of this PR? There have been no updates for a month.

[natalie-perlin]

@natalie-perlin - what is the status of this PR? There have been no updates for a month.

@GeorgeGayno-NOAA - will be able to get back to it again. Some higher priorities with the UFS weather-model work had to be completed first...

[GeorgeGayno-NOAA]

@natalie-perlin - what is the status of this PR?