Yes, VecRestoreArray[Read,Write] should be called after you finish using
the array. This casting to (const double **) is bad. Otherwise, compiler
could catch the error when you use a const pointer in a non-const way.
PetscCall(VecGetArrayRead(ref, (const double **)())) ;
After I used the
> On 26 Jan 2024, at 3:11 PM, Pierre Jolivet wrote:
>
>>
>> On 26 Jan 2024, at 3:03 PM, mich...@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:
>>
>>
> On 26 Jan 2024, at 3:03 PM, mich...@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
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
petsc main in debug mode has some additional checks for this cases. Can you
run with the main branch and configure petsc using --with-debugging=1?
Il giorno mar 23 gen 2024 alle ore 22:35 Barry Smith ha
scritto:
>
>This could happen if the values in the vector get changed but the
>
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
Do you have an example to reproduce it?
--Junchao Zhang
On Tue, Jan 23, 2024 at 10:49 AM 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:
>
>
