> On Jul 28, 2017, at 2:13 PM, Richard Tran Mills <[email protected]> wrote:
>
> On Fri, Jul 28, 2017 at 12:02 PM, Stefano Zampini <[email protected]>
> wrote:
> MatShift, MatZeroEntries…. there are for sure others that modify the entries.
> I would suggest you to quickly go over the online Mat pages.
>
> Just a curiosity: Why the inspector should care about the magnitude of the
> entries?
> If it’s clear in the code how to change the entry of the CSR that the
> inspector uses (not the CSR itself, just the values), then the missing
> functions can be fixed later.
>
> The inspector shouldn't care, of course, at all about the magnitude of the
> entries since it is only looking at the sparsity pattern. Unfortunately, the
> the MKL sparse inspector-executor routines store things in an internal
> representation that I cannot modify; I just have to tell MKL to rebuild the
> data structure. It doesn't use the A,I,J arrays that PETSc has after these
> are used by mkl_sparse_optimize().
They will eventually support a "updated numerical values only" option.
Richard
In theory PETSc Mat have two "state" values,
1) nonzerostate - this is increased anytime the nonzero structure changes
2) state - this is increased anytime any numerical values are changed
These are used by PCSetUp() to determine if the preconditioner needs to be
updated and if that involves a new nonzero structure.
The reason I say "in theory" is that it looks like certain changes to matrices
do not properly update the state.
Barry
Vec also has a state variable and this is used to insure that cached norms are
up to date.
>
> --Richard
>
>
>
> > On Jul 28, 2017, at 9:58 PM, Barry Smith <[email protected]> wrote:
> >
> >
> >> On Jul 28, 2017, at 12:50 PM, Richard Tran Mills <[email protected]> wrote:
> >>
> >> Folks,
> >>
> >> I've been debugging my rmills/add-aijmkl branch, and I found that one bug
> >> I had was related to what happens when I am using the MKL sparse
> >> inspector-executor routines inside an AIJMKL matrix and then MatScale is
> >> called on the matrix. MatScale modifies the entries of the matrix, thereby
> >> invalidating the internal representation that the MKL routines use.
> >> Currently, I've set things up so that the MKL representation is only
> >> updated in MatAssemblyEnd_SeqAIJMKL and MatDuplicate_SeqAIJMKL. Looks like
> >> I also need a MatScale_SeqAIJMKL that will update the MKL representation
> >> when needed. Are there other routines that may modify the matrix entries
> >> without invoking MatAssemblyEnd?
> >
> > There is no general "rule"; generally any method that could result in a
> > different nonzero pattern results in calls to the MatAssemblyEnd... but
> > otherwise they likely do not call it. MatDiagonalScale() is a candidate.
> >
> > Barry
> >
> >>
> >> --Richard
> >
>
>
