Reduce dependency on SPLIB

[GeorgeGayno-NOAA]

DESCRIPTION OF CHANGES:

Reduce UFS_UTILS dependency on SPLIB.

orog program -

• Remove routines MAKEMT, MAKEPC and MAKEOA, which were used for the old spectral GFS gaussian grid (and have dependencies on SPLIB) and are now obsolete.
• Remove write of the GRIB1 version of the 'orog' file. That was only used for the old spectral GFS and had dependencies on SPLIB.
• Remove write of old binary version of the 'orog' file, which was used for the old spectral GFS.
• Remove BACIO library from the build.
• Remove unused variables and perform some general cleanup.

TESTS CONDUCTED:

If there are changes to the build or source code, the tests below must be conducted. Contact a repository manager if you need assistance.

• Compile branch on all Tier 1 machines using Intel (Orion, Jet, Hera, Hercules and WCOSS2). Done using 1b0dc95.
• Compile branch on Hera using GNU. Done using 1b0dc95.
• Compile branch in 'Debug' mode on WCOSS2. Done using 1b0dc95..
• Run unit tests locally on any Tier 1 machine. Done on Hera using 1b0dc95.
• Run relevant consistency tests locally on all Tier 1 machine. Ran the grid_gen tests using 1b0dc95. All passed as expected.

Describe any additional tests performed.

• Compiled the Doxygen with no warnings.

DEPENDENCIES:

N/A

DOCUMENTATION:

N/A

ISSUE:

Fixes #886.

[GeorgeGayno-NOAA]

@AlexanderRichert-NOAA - would you be willing to review?

[AlexanderRichert-NOAA]

Sure. Two things right off the bat: We just merged sp into ip, so these functions are available there. Would it make sense to use the ones available through ip? It would require moving to the latest release, so that's the main tradeoff that comes to mind.
The other issue is that the LU decomposition routines in lapack_gen are from Numerical Recipes and therefore copyrighted and shouldn't be used. I'm still working on coming up with a replacement for them in sp/ip... I got as far as identifying some possible replacements, either open source routines we could copy/paste or possibly an external linear algebra library.

[GeorgeGayno-NOAA]

Sure. Two things right off the bat: We just merged sp into ip, so these functions are available there. Would it make sense to use the ones available through ip? It would require moving to the latest release, so that's the main tradeoff that comes to mind. The other issue is that the LU decomposition routines in lapack_gen are from Numerical Recipes and therefore copyrighted and shouldn't be used. I'm still working on coming up with a replacement for them in sp/ip... I got as far as identifying some possible replacements, either open source routines we could copy/paste or possibly an external linear algebra library.

Thanks, I did not realize that lapack_gen was copyrighted. I reverted my updates to weight_gen.

I started this work before the final decision was made to merge sp into ip. I still want to keep my changes to the orog code as I removed options that are now obsolete under the UFS model. This was a good opportunity to do some housekeeping.

[AlexanderRichert-NOAA]

If you keep the 'sp' requirement removed in that CMake config, then I think you'll want to update the root CMakeLists.txt to require ip v5 or higher and remove sp (or add some logic to make it dependent on the ip version number).

[GeorgeGayno-NOAA]

Need to revert this PR. When creating a C96 uniform grid using the scripts in ./driver_scripts, I get a segmentation fault when the orog code is run the second time (after the lake and ocean merge steps). This was not caught because none of the consistency tests test this particular configuration. A new test must be added.

The segmentation fault is consistent on both Hera and Orion. Tests using the splib branch showed the problem starting at 45bdf01. Tile1 ran fine. Tile 2 broke here:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
orog               00000000004DB19A  Unknown               Unknown  Unknown
libpthread-2.17.s  00002B2632D235D0  Unknown               Unknown  Unknown
libiomp5.so        00002B26330795EC  Unknown               Unknown  Unknown
libiomp5.so        00002B26330795BA  Unknown               Unknown  Unknown
libiomp5.so        00002B263307B6AF  Unknown               Unknown  Unknown
orog               000000000050D6EC  Unknown               Unknown  Unknown
orog               000000000041B838  tersub_                   950  mtnlm7_oclsm.F
orog               000000000040DFCF  MAIN__                    138  mtnlm7_oclsm.F

Tile 3 broke here:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
orog               00000000004DB19A  Unknown               Unknown  Unknown
libpthread-2.17.s  00002B4FD45E05D0  Unknown               Unknown  Unknown
libiomp5.so        00002B4FD49365EC  Unknown               Unknown  Unknown
libiomp5.so        00002B4FD49365BA  Unknown               Unknown  Unknown
libiomp5.so        00002B4FD49386AF  Unknown               Unknown  Unknown
orog               000000000050D6EC  Unknown               Unknown  Unknown
orog               0000000000411818  tersub_                   440  mtnlm7_oclsm.F
orog               000000000040DFCF  MAIN__                    138  mtnlm7_oclsm.F
orog               000000000040D192  Unknown               Unknown  Unknown

This PR was created to reduce the UFS_UTILS dependency on SPLIB. Since it was later decided to merge all of SPLIB into IPLIB, fixing this PR will be low priority.