[petsc-users] Bug in VecNorm, 3.20.3

[Pierre Jolivet]

> On 26 Jan 2024, at 3:11 PM, Pierre Jolivet <pierre at joliv.et> wrote:
> 
>> 
>> On 26 Jan 2024, at 3:03 PM, michael at paraffinalia.co.uk wrote:
>> 
>> On 2024-01-23 18:09, Junchao Zhang wrote:
>>> Do you have an example to reproduce it?
>>> --Junchao Zhang
>> 
>> I have put a minimum example on github:
>> 
>> https://github.com/mjcarley/petsc-test
>> 
>> It does seem that the problem occurs if I do not use the PETSc interface to do a matrix multiplication.
>> 
>> In the original code, the PETSc matrix is a wrapper for a Fast Multipole Method evaluation; in the minimum example I have simulated this by using an array as a matrix. The sample code generates a randomised matrix A and reference solution vector ref, and generates a right hand side
>> 
>> b = A*ref
>> 
>> which is then supplied as the right hand side for the GMRES solver. If I use the PETSc matrix multiplication, the solver behaves as expected; if I generate b directly from the underlying array for the matrix, I get the result
> 
> You should not use VecGetArrayRead() if you change the Vec, but instead, VecGetArrayWrite().
> Does that solve the issue?

Sorry, I sent the message too fast, you are also missing a couple of calls to VecRestoreArray[Read,Write]().
These are the ones which will let PETSc know that the Vec has had its state being increased, and that the cached norm are not valid anymore, see https://petsc.org/release/src/vec/vec/interface/rvector.c.html#line2177

Thanks,
Pierre

> Thanks,
> Pierre
> 
>> 0 KSP Residual norm < 1.e-11
>> Linear solve converged due to CONVERGED_ATOL iterations 0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240126/c9febde9/attachment-0001.html>