Fix PETSc 3.24 deprecated warnings

[jwpeterson]

I don't have PETSc 3.24 installed, so this is going to be coding via CI...

[jwpeterson]

Note: if this passes the "Test mac" target, we should be good. That is the only one that seems to be failing due to deprecation warnings (since -Werror is turned on).

[roystgnr]

we should be good.

Huh; I see someone has renamed the "Hubris check" recipe to "Min gcc". ;-)

[jwpeterson]

Well, this is interesting. The "Min gcc" build uses PETSc 3.22.1,

<<< Found PETSc 3.22.1 installation in /opt/petsc ... >>>

but for some reason it's reaching the #else clause of the code I just added:

../src/solvers/petsc_linear_solver.C: In member function 'virtual libMesh::LinearConvergenceReason libMesh::PetscLinearSolver<T>::get_converged_reason() const':
../src/solvers/petsc_linear_solver.C:780:10: error: 'KSP_CONVERGED_RTOL_NORMAL_EQUATIONS' was not declared in this scope
     case KSP_CONVERGED_RTOL_NORMAL_EQUATIONS : return CONVERGED_RTOL_NORMAL;
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/solvers/petsc_linear_solver.C:780:10: note: suggested alternative: 'KSP_CONVERGED_RTOL_NORMAL'
     case KSP_CONVERGED_RTOL_NORMAL_EQUATIONS : return CONVERGED_RTOL_NORMAL;
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          KSP_CONVERGED_RTOL_NORMAL
../src/solvers/petsc_linear_solver.C:781:10: error: 'KSP_CONVERGED_ATOL_NORMAL_EQUATIONS' was not declared in this scope
     case KSP_CONVERGED_ATOL_NORMAL_EQUATIONS : return CONVERGED_ATOL_NORMAL;
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/solvers/petsc_linear_solver.C:781:10: note: suggested alternative: 'KSP_CONVERGED_ATOL_NORMAL'
     case KSP_CONVERGED_ATOL_NORMAL_EQUATIONS : return CONVERGED_ATOL_NORMAL;
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          KSP_CONVERGED_ATOL_NORMAL

[jwpeterson]

That doesn't make any sense to me, unless something is wrong with our macro (that just calls the PETSc macro) in that version of PETSc?

#define PETSC_VERSION_LESS_THAN(major,minor,subminor) \
  PETSC_VERSION_LT(major,minor,subminor)

[moosebuild]

Job Coverage, step Generate coverage on aeeb8a7 wanted to post the following:

Coverage

Coverage did not change

Full coverage report

This comment will be updated on new commits.

[jwpeterson]

@roystgnr the error on the Min gcc (PETSc 3.22.1) build refers to line 780, a line that should only be seen by PETSc >= 3.24.0. Do you know if there's anything different about the build environment for that recipe that would somehow cause us to configure against one PETSc version and then actually build against another??

[lindsayad]

The way that PETSc macro works is that if the PETSc hash points to a non-release hash, then its version is effectively infinite. The idea is that you either keep up-to-date on cutting edge main or you use PETSc's release branch and the tags on it. This is ultimately probably my fault because I updated PETSc at one point to a non-release hash and now it corresponds to our min tag

[lindsayad]

So this will require a civet recipes fix, which I hope we can get done in the next day or so

[jwpeterson]

OK, I was fooled by Min gcc reporting that it was using PETSc "3.22.1" during configure... I assumed that meant it was a release. Maybe our configure could be a little more helpful here and also print the value of PETSC_VERSION_RELEASE.

[moosebuild]

Job Min gcc on aeeb8a7 : invalidated by @loganharbour

Bump min gcc container to current moose

[loganharbour]

@lindsayad @jwpeterson: bumped the min gcc environment here. Let me know if there are any other issues

[loganharbour]

We do keep all of the libmesh-only environments static. The MOOSE environments use the latest moose environment. What do we think about adding a libmesh-only test that uses the latest MOOSE environment? Allowed to fail. But it'll at least get us some coverage for libmesh tests with whatever is latest. That can be fixed over time.

[jwpeterson]

Let me know if there are any other issues

@loganharbour there now seems to be an issue with configure:

configure: error: HDF5 was not built with zlib, which is required. Rebuild HDF5 with zlib.
configure: error: ../../../../contrib/netcdf/netcdf-c/configure failed for contrib/netcdf/netcdf-c

FYI we have also seen this failure on the libmesh "Test MOOSE PETSc" recipe on the devel -> master merge (https://civet.inl.gov/branch/14145). So, I think there may be some issue with that environment, but I don't know why it's different from others.

[lindsayad]

I'll try to see what's going on here. I think we've downloaded hdf5 and configured with zlib (from PETSc) for as long as I can remember

[jwpeterson]

Seems like the zlib package might be missing from the system image used for the install.

[lindsayad]

So zlib isn't missing on the system, it's just that with newer versions of PETSc (it is a bit funny that the gcc min target is now bringing in a PETSc of 3.24 whereas our other testing is using PETSc 3.20) it seems that we aren't configuring hdf5 properly to bring in zlib. We need to pass --with-zlib to PETSc in order to get that option into the hdf5 configuration. Also this is only an issue with the newer netcdf5. The explicit check for H5_HAVE_ZLIB_H in netcdf configure is not present in the default netcdf 4.6.2

[lindsayad]

We do keep all of the libmesh-only environments static. The MOOSE environments use the latest moose environment. What do we think about adding a libmesh-only test that uses the latest MOOSE environment? Allowed to fail. But it'll at least get us some coverage for libmesh tests with whatever is latest. That can be fixed over time.

This would be great. This would have caught the issue now present in the gcc min target much much sooner

[lindsayad]

The new target should use netcdf 4.9.2

[lindsayad]

I'm fixing the PETSc configuration of hdf5 in idaholab/moose#31768

[loganharbour]

Updated min gcc (temporarily) from the one in the above PR.

Can merge if you want, but the environment will change to the production environment once it gets past next