[petsc-dev] MatXXXSetPreallocation and -mat_new_nonzero_allocation_error

Jed Brown jed at 59A2.org
Thu Apr 22 13:55:12 CDT 2010

On Thu, 22 Apr 2010 08:48:08 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote:
>     Good suggestion. Now the question is do we put it in the "right"  
> place which is MatSetFromOptions(), but most people never call  
> MatSetFromOptions() so should we put in the "ideological wrong place"  
> MatCreate() since that means it will always be available?

Okay, so something I've been meaning to do is to implement
MatXXXSetPreallocation for every less structured matrix type.  The most
structured PETSc type is MPISBAIJ, so if you have one of these guys, you
would call


and have a correctly preallocated matrix for {Seq,MPI}{,B,SB}AIJ, with
blocks size set for the AIJ formats.  Similarly for the other levels of
the hierarchy.  This is a change that would affect a lot of existing
code because all the places where people currently call


would cause a bunch of unnecessary allocations for -mat_type seqaij
(because every one would be implemented, thus freeing the old memory and
reallocating the same memory again).  If the top version worked for all
matrix types, we could even consider getting rid of the convenience
MatCreateXXX() functions because that interface is so limiting.

In other words, I think that the presence of the convenience functions
is motivated by simplifying four lines that do the same thing *and* for
which the user would have to write significantly more code to get
significantly more functionality.  If those four lines offered much
greater capability than the convenience functions, then perhaps the
convenience functions can be eliminated, and then
-mat_new_nonzero_allocation_error can be put in the Right Place.
Getting users to create matrices this way (calling MatSetFromOptions())
would also allow a bunch of other options to be documented via -help,
such options are currently difficult to learn about.



More information about the petsc-dev mailing list