[petsc-users] Bug in VecNorm, 3.20.3

[Barry Smith]

   This could happen if the values in the vector get changed but the PetscObjectState does not get updated. Normally this is impossible, any action that changes a vectors values changes its state (so for example calling VecGetArray()/VecRestoreArray() updates the state. 

   Are you accessing the vector values in any non-standard way? 

   Barry


> On Jan 23, 2024, at 11:39 AM, michael at paraffinalia.co.uk wrote:
> 
> Hello,
> 
> I have used the GMRES solver in PETSc successfully up to now, but on installing the most recent release, 3.20.3, the solver fails by exiting early. Output from the code is:
> 
> lt-nbi-solve-laplace: starting PETSc solver [23.0537]
>  0 KSP Residual norm < 1.e-11
> Linear solve converged due to CONVERGED_ATOL iterations 0
> lt-nbi-solve-laplace: 0 iterations [23.0542] (22.9678)
> 
> and tracing execution shows the norm returned by VecNorm to be 0.
> 
> If I modify the function by commenting out line 217 of
> 
>  src/vec/vec/interface/rvector.c
> 
>  /* if (flg) PetscFunctionReturn(PETSC_SUCCESS); */
> 
> the code executes correctly:
> 
> lt-nbi-solve-laplace: starting PETSc solver [22.9392]
>  0 KSP Residual norm 1.10836
>  1 KSP Residual norm 0.0778301
>  2 KSP Residual norm 0.0125121
>  3 KSP Residual norm 0.00165836
>  4 KSP Residual norm 0.000164066
>  5 KSP Residual norm 2.12824e-05
>  6 KSP Residual norm 4.50696e-06
>  7 KSP Residual norm 5.85082e-07
> Linear solve converged due to CONVERGED_RTOL iterations 7
> 
> My compile options are:
> 
> PETSC_ARCH=linux-gnu-real ./configure --with-mpi=0 --with-scalar-type=real --with-threadsafety --with-debugging=0 --with-log=0 --with-openmp
> 
> uname -a returns:
> 
> 5.15.80 #1 SMP PREEMPT Sun Nov 27 13:28:05 CST 2022 x86_64 Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz GenuineIntel GNU/Linux
>