Update to bufr/11.7.0, add safeguard to avoid out of bounds reference…

[RussTreadon-NOAA]

This PR is opened to request the addition of two updates to release/gfsda.v16.3.0. These changes are in response to

• a request from NCO to update to bufr/11.7.0
• identification of a case in which the -check all build of gsi.x seg faults

Please see issue #474 for details.

Neither of these changes alter gsi.x analysis results in testing to date.

[ShunLiu-NOAA]

The changes looks good to me.

[RussTreadon-NOAA]

Thank you, @ShunLiu-NOAA

[RussTreadon-NOAA]

Please note that when gfsda.v16.3.0 is built within the global-workflow, build versions are defined by g-w versions/build.ver. The gfsda.v16.3.0 build only uses the updated default versions in gsi_common.lua and gsi_wcoss2.lua when the the version variable is not defined.

Thus, for NCO to actually see a change in the versions used to build gfsda.v16.3.0 updated versions must be committed to g-w versions/build.ver in release/gfs.v16.3.0.

[emilyhcliu]

@RussTreadon-NOAA
Based on your explanation above, even if we do not update the module versions in GSI (gsi_common.lua and gsi_wcoss2.lua), the g-w will build the GSI based on the versions/build.ver in g-w.

I am asking this because Rahul asked Lin to update the gfs.v16.3.0 global-workflow (versions/build.ver) based on NCO's request this morning.

craype 2.7.10 -> 2.7.13
Prgv-Intel 8.1.0 -> 8.2.0
cray-mpich 8.1.9 -> 8.1.12
cray-pals 1.0.17 -> 1.1.3
bufr 11.4.0 -> 11.7.0

But, we have not update our gfsda.v16.3.0 tag to use the 5 updated versions above.
My understanding is the following:
As long as Lin updated the versions/build.ver in g-w, the GSI should be compiled with the versions specified in g-w versions/build.ver.

Am I correct?

[RussTreadon-NOAA]

Yes, this is correct. That's why I added my note to this PR. I believe it is best to keep gsi_common.lua and gsi_wcoss2.lua consistent with how g-w builds. This way a stand-alone build of release/gfsda.v16.3.0 reproduces what NCO builds inside g-w.

[RussTreadon-NOAA]

@emilyhcliu , where are the HOMEgfs and log files for Lin's build and test? The best way to see what was used is to check logs.

[RussTreadon-NOAA]

A short operational resolution parallel has been run on Cactus over the period 2022010306 - 2022010400. The parallel was warm started from the EIB retro1-v16-ecf. A spot check of enkfgdas, gdas, and gfs output from 2022010400 shows it to be identical with retro1-v16-ecf output.

The one exception to this is that the test generates atmfXXX.enspread.nc files. These files are not generated in the retro1-v16-ecf due to the getsigensmeanp_smooth_ncep.f90 bug described in issue #474.

[RussTreadon-NOAA]

One additional note regarding the release/gfsda.v16.3.0 build. Even though gsi_wcoss2.lua updates the cray-mpich version from 8.1.2 to 8.1.12, the following modules built with cray-mpich/8.1.4

• ncio/1.0.0
• nemsio/2.5.2
• netcdf/4.7.4
• wrf_io/1.1.1

The 8.1.4 modules are used when building release/gfsda.v16.3.0. EIB and NCO are aware of this. These packages should be built using cray-mpich/8.1.12

[RussTreadon-NOAA]

Extend Cactus run to 2022010406 with release/gfsda.v16.3.0 recompiled using -check all. All DA executables in 2022010406 gdas and enkfgdas jobs ran to completion without any run time errors.

[emilyhcliu]

@RussTreadon-NOAA Based on latest Rahul's e-mail (7 minutes ago) about the library update for gfs.v16.3.0. There is a decision from NCO and EMC management that gfs.v16.3.0 will only need to upgrade BUFR from 11.4.0 to 11.7.0.
So, we should revert the changes in the gsi_wcoss2.lua to the original.

[RussTreadon-NOAA]

Yes, I saw this ... after all the tests were completed with the change. I will revert the changes to gsi_wcoss2.lua. I will not rerun all the tests.

[RussTreadon-NOAA]

@emilyhcliu , requested change made. Please review.

[emilyhcliu]

Changes look good!