[petsc-dev] Putting solver state into vectors

Jed Brown jed at jedbrown.org
Mon Jan 19 06:44:33 CST 2015


Matthew Knepley <knepley at gmail.com> writes:

> On Sun, Jan 18, 2015 at 11:02 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>> > I agree completely. If we need more state, it should go in the solver.
>>
>> Solve the ABA problem without marking the Vec.
>>
>
> Why do we have an ABA problem?

And this is why private threads waste time.  From the other conversation:

Jed wrote:
> Barry wrote:
> >    Then you can keep your horrible stashing of SOLVER state that
> >    belongs in the solver not in the vector but it is still the wrong
> >    model. Solver state never belongs in a vector (except possibly as
> >    an error check but never as the place to store the one copy of that
> >    state information).
> 
> What we're doing is equivalent to snapshotting the value of obj->state
> and checking whether it still matches what we had last time.  Except
> that the user could change ts->vec_sol, so we'd have to also store the
> value of ts->vec_sol.  But the user could destroy ts->vec_sol, allocate
> a new one, and get back the same pointer address (unlikely, but it's
> called the "ABA problem").  Also, this doesn't solve the behavioral
> problem you're objecting to.

In that thread, Barry liked the idea of VecLock and put forward a
proposal for erroring by default if the user modifies the state from a
callback, and an interface for allowing it:

-------------- next part --------------
An embedded message was scrubbed...
From: Barry Smith <bsmith at mcs.anl.gov>
Subject: Re: PetscObjectComposedDataGet/SetReal in ARKIMEX
Date: Sun, 18 Jan 2015 16:31:52 -0600
Size: 9014
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150119/e0257ce7/attachment.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150119/e0257ce7/attachment.sig>


More information about the petsc-dev mailing list