[petsc-dev] matrix duplication

[Barry Smith]

   Mumps and SuperLU, like all sparse solver packages we know of, have their own storage format that you need to put the matrix into before calling their factorization routines. Thus we need to copy from our format to theirs.

1)  Note that compared to the memory and work of a full factorization this copy is a trivial percentage of the time and small percentage of space so is generally not a big deal.

2)  If, for some reason, someone decided they hated this copy so much, they could provide a new PETSc Mat storage format that was exactly what these packages expected and provide MatSetValues(), MatAssemblyBegin/End() etc etc for that new format and register the new matrix type and use it when creating the matrix and skip the copy step. But note that this is a relatively large amount of coding work so should only be done if one knows the copy is having a big impact on performance. In our timings the copy was trivial compared to the rest so we have no motivation to do all that work.

3) The reason we "save" the the copy in the factor matrix is for repeated solves with different matrices (and same nonzero pattern). We can reuse that data structure for the next solve. One could, of course, delete that data structure once the matrix is factored and create it again later as needed for a new matrix but that doesn't change the "high water mark" for memory usage so we keep it around and reuse it.  For factorizations with separate symbolic and numeric portions one can also reuse the symbolic part for the next matrix (with same nonzero structure of course).  Whether you save this "copy" or not is just a decision internal to the design of that particular solver interface and is up to you.

   Barry

On Sep 18, 2013, at 12:49 PM, Jose David Bermeol <jbermeol at purdue.edu> wrote:

> Hi, one question, why do mumps and superLu have to make copies of the matrix A(no complete copies, but at least the structure and the values) and saved in the factor matrix?
> 
> Thanks