[petsc-dev] MatXXXSetPreallocation and -mat_new_nonzero_allocation_error

[Barry Smith]

   I don't understand how knowing the preallocation for SBAIJ give you  
an efficient way to know the preallocation for BAIJ?  Say you have  
20,000 processors can you efficiently get the information where it is  
needed? Are you willing to write the code to do that?

    Barry

On Apr 22, 2010, at 1:55 PM, Jed Brown wrote:

> 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
>
>  MatCreate
>  MatSetSizes
>  MatSetFromOptions
>  MatMPISBAIJSetPreallocation
>
> 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
>
>  MatSeqAIJSetPreallocation
>  MatMPIAIJSetPreallocation
>  MatSeqBAIJSetPreallocation
>  MatMPIBAIJSetPreallocation
>  MatSeqSBAIJSetPreallocation
>  MatMPISBAIJSetPreallocation
>  MatSetBlockSize
>
> 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.
>
> Comments?
>
> Jed