Note that all error codes in PETSc are fatal, and we don't handle these
cases gracefully. So, code like this
ierr = SNESSolve(snes,...);
if (ierr) {
" do something and expect PETSc will keep working as usual"
}
is not supported in general.
However, an SNES that does not converge should not generate an error, but
rather return a negative SNESConvergedReason.
Maybe you are using -snes_error_if_not_converged (via command line) or
calling SNESSetErrorIfNotConverged at some point in the code.
You can then do
PetscCall(SNESSolve(snes,...);)
PetscCall(SNESGetConvergedReason(snes,&reason...);)
if (reason < 0) {
" now you can do whatever you want and PETSc will keep working as usual"
}
Il giorno mer 17 dic 2025 alle ore 22:09 David Knezevic <
[email protected]> ha scritto:
> Hi,
>
> I'm using PETSc via the libMesh framework, so creating a MWE is
> complicated by that, unfortunately.
>
> The situation is that I am not modifying the solution vector in a
> callback. The SNES solve has terminated, with PetscErrorCode 82, and I then
> want to update the solution vector (reset it to the "previously converged
> value") and then try to solve again with a smaller load increment. This is
> a typical "auto load stepping" strategy in FE.
>
> I think the key piece of info I'd like to know is, at what point is the
> solution vector "unlocked" by the SNES object? Should it be unlocked as
> soon as the SNES solve has terminated with PetscErrorCode 82? Since it
> seems to me that it hasn't been unlocked yet (maybe just on a subset of the
> processes). Should I manually "unlock" the solution vector by
> calling VecLockWriteSet?
>
> Thanks,
> David
>
>
>
> On Wed, Dec 17, 2025 at 2:02 PM Stefano Zampini <[email protected]>
> wrote:
>
>> You are not allowed to call VecGetArray on the solution vector of an SNES
>> object within a user callback, nor to modify its values in any other way.
>> Put in C++ lingo, the solution vector is a "const" argument
>> It would be great if you could provide an MWE to help us understand your
>> problem
>>
>>
>> Il giorno mer 17 dic 2025 alle ore 20:51 David Knezevic via petsc-users <
>> [email protected]> ha scritto:
>>
>>> Hi all,
>>>
>>> I have a question about this error:
>>>
>>>> Vector 'Vec_0x84000005_0' (argument #2) was locked for read-only access
>>>> in unknown_function() at unknown file:0 (line numbers only accurate to
>>>> function begin)
>>>
>>>
>>> I'm encountering this error in an FE solve where there is an error
>>> encountered during the residual/jacobian assembly, and what we normally do
>>> in that situation is shrink the load step and continue, starting from the
>>> "last converged solution". However, in this case I'm running on 32
>>> processes, and 5 of the processes report the error above about a "locked
>>> vector".
>>>
>>> We clear the SNES object (via SNESDestroy) before we reset the solution
>>> to the "last converged solution", and then we make a new SNES object
>>> subsequently. But it seems to me that somehow the solution vector is still
>>> marked as "locked" on 5 of the processes when we modify the solution
>>> vector, which leads to the error above.
>>>
>>> I was wondering if someone could advise on what the best way to handle
>>> this would be? I thought one option could be to add an MPI barrier call
>>> prior to updating the solution vector to "last converged solution", to make
>>> sure that the SNES object is destroyed on all procs (and hence the locks
>>> cleared) before editing the solution vector, but I'm unsure if that would
>>> make a difference. Any help would be most appreciated!
>>>
>>> Thanks,
>>> David
>>>
>>
>>
>> --
>> Stefano
>>
>
--
Stefano
