[petsc-dev] What should MatReset() do?

[Dmitry Karpeyev]

On Thu, Feb 26, 2015 at 8:03 AM Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:

> On Wed Feb 25 2015 at 10:56:30 PM Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>> > On Feb 25, 2015, at 10:45 PM, Dmitry Karpeyev <karpeev at mcs.anl.gov>
>> wrote:
>> >
>> > Since user callbacks, such as the one to compute the Jacobian, are now
>> supposed to modify matrices in place, we need to provide the equivalent of
>> MatReset() so that the user can do things like reset the sparsity pattern,
>> etc. What should that call do?
>> >
>> > I assume it would keep the type, sizes and the block size of the matrix
>> and reset everything else.   The impl-specific stuff is handled by
>> MatDestroy(), but what about the generic data members?  I imagine that the
>> structural properties, such as symmetry and others set with MatSetOption()
>>
>> Yes (this is in analogy to how KSPReset etc work, they clean out data
>> objects but keep the options the user has selected for them)
>>
>> > as well as MatFactorType and MatStencilInfo should be preserved,
>>
>>
>> Don't know about these.
>>
>> > while MatRedundant and the (Near)NullSpace have to go.
>>
>>   Yes
>>
>> > What about the logging info? num_ass?
>>
>>   Keep I think
>> >  Do we increment nonzerostate or reset it?
>>
>> increment
>>
>
This is trickier than it might appear: nonzerostate effectively counts the
global number of nonzeros. The PC will rebuild if its state is stale, but
it will reuse matrices (e.g., subdomain matrices in PCASM) if nonzerostate
is up to date.  This works if the sparsity pattern never drops nonzeros,
but that's no longer true if reset is allowed. I can reset a matrix,
preallocate and assemble it so that the global number of nonzeros will be
the same as before the resetting, but local sparsity patterns will change.
This could happen, for example, when I have moving particles or, less
exotically, when I have elastic contact and nodes move past each other.
That will break PCASM.

As far as I can tell this is a bug, since, in principle, we allow MatType
to be reset, which is equivalent to MatReset(). In part that's what
enables the  SNES Jacobian callback to take Mat arguments, rather than
Mat*.  I'm not sure how to fix this in maint, though.  In master we could
add a resetcounter and have PC check that in addition to nonzerostate, but
that seems to be too intrusive for maint.

Dmitry.


>
>> >  The PetscObject state?
>>
>> increment
>>
> Yes, these two need to be incremented, as I realized, to avoid a situation
> where the same Mat object with a completely different structure has the
> same state index as a previous incarnation.  The PC will think it doesn't
> need to rebuild ...
>
>>
>> > I don't know what to do about the GPU pointers.
>>
>> I would clean those all out.
>>
> I'm not sure how -- isn't freeing these implementation-dependent?
>
>
>> >
>> > While MatReset() isn't yet available,  MatSetType(mat,newtype);
>> MatSetType(mat,oldtype); should have the same effect,
>> > but it doesn't, which to me is a bug
>>
>>    I agree it seems like a bug
>>
>> > and I'd like to fix it in maint.
>> > It would be good, however, to do it "right" by answering the questions
>> above.  Any opinions?
>> >
>> > Dmitry.
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150306/6720c6af/attachment.html>