GMAO_Transf build options causing IAU to crash but fix makes code non-zero diff when using stochastic physics but then matches CVS.

[bena-nasa]

When trying to debug a crash when using the spectral filter in mkiau we found that the CMakeLists.txt file in GMAO_transf was causing the final GEOSgcm.x executable to link to the R8I4 version of NCEP_sp because that is what GMAO_transf was using to make the library. While the GNUmake version was also telling it to use the R8I4 version the final GEOSgcm.x was linking to the R4I4 version. Apparently linking to the R8I4 version in the GEOSgcm.x was causing a crash in the spectral filter when exercising this feature in mkiau. We did an experiment where we told GMAO_transf to link to the R4I4 version of NCEP_sp. This caused the GEOSgcm.x to link to the R4I4 version and fixed the IAU issue but it is a non-zero diff change when exercising the stochastic physics.

However only with this change is the result when using the stochastic physics matching the CVS result. In other words our current GEOSgcm.x is non-zero diff when exercising the stochastic physics option in git relative to cvs.

[rtodling]

Ben, unfortunately this is a problem and I don't think we can just move on and accept the non-zero diff in the stochastic perturbation code. At the very least we must make sure the stochastic patterns are correct and there isn't some sort of hidden issue that does not pop the eye.

[bena-nasa]

We don't have to accept this non-zero diff change. We can match the CVS answer by linking to the R4I4 version in the final GEOSgcm.x which is what the GNUmake build is doing. This also fixes the JCAP issue. Not sure why the GNUmakefile in CVS was linking to the R8I4 version, cmake certainly built linking the library to the R4I4 version and reproduced the CVS answer.

[bena-nasa]

Just tried building the transf library in the CVS/GNUmake Jason-3_2 version linking to the R4I4 version of NCEP_sp (the current code says to use the R8I4 version), the library built, relinked the GEOSgcm.x, and the answer is zero diff. Clearly the loader must be using the R4I4 version no matter what transf is built with and it has been this way all along. NCEP_sp appears to be entirely Fortran77 ish code, all subroutines, no modules so not surprising transf will link to whatever you throw at it.