On Fri, Jul 28, 2017 at 12:32 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
> > > On Jul 28, 2017, at 2:13 PM, Richard Tran Mills <rtmi...@anl.gov> wrote: > > > > On Fri, Jul 28, 2017 at 12:02 PM, Stefano Zampini < > stefano.zamp...@gmail.com> 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. > Hi Barry: Sounds good. In the meantime, I'm simply making a corresponding _SeqAIJMKL version of all of the functions in question that will just call the _SeqAIJ version and then call a function that creates an updated MKL sparse matrix handle. It appears that several of these do not have function prototypes in any of the .h files (they haven't been needed outside of aij.c). I assume I can just add PETSC_INTERN prototypes in src/mat/impls/aij/seq/aij.h (where we have things like prototypes for MatAssemblyEnd_SeqAIJ)? Or is there some reason we want to keep these functions more hidden? I could just declare prototypes in aijmkl.c, but that seems worse in my mind: If someone changes an interface in aij.c, then changing the prototype in aij.h is something they might think of, but I don't think they'll necessarily know to do so in aijmkl.c. --Richard > 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 <bsm...@mcs.anl.gov> wrote: > > > > > > > > >> On Jul 28, 2017, at 12:50 PM, Richard Tran Mills <rtmi...@anl.gov> > 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 > > > > > > > > >
