> On Jul 28, 2017, at 7:12 PM, Richard Tran Mills <rtmi...@anl.gov> wrote: > > 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)?
I think this is the correct place. If they have static in front of them you will need to remove that also. > 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 > > > > > > > > >
