On Wed Feb 25 2015 at 10:56:30 PM Barry Smith <[email protected]> wrote:
> > > On Feb 25, 2015, at 10:45 PM, Dmitry Karpeyev <[email protected]> > 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 > > > 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. > > > >
