dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, May 16, 2008 at 10:50:48PM -0500, Andy Ray Terrel wrote:
> In PETScMatrix::init(uint M, uint N, const uint* nz), you see the following:
> 
>     MatCreate(PETSC_COMM_SELF, &A);
>     MatSetSizes(A,  PETSC_DECIDE,  PETSC_DECIDE, M, N);
>     setType();
>     MatSeqAIJSetPreallocation(A, PETSC_DEFAULT, (int*)nz);
>     MatSetFromOptions(A);
>     MatSetOption(A, MAT_KEEP_ZEROED_ROWS,PETSC_TRUE);
>     MatZeroEntries(A);
> 
> 
> Since MatSetFromOptions follows MatSeqAIJSetPreallocation, when I have tried to
> use a different mat_type from the petsc command line arguments the
> preallocation data is getting thrown away.  If we switch the order of these two
> calls, it works fine if I use a matrix derived from SeqAIJ.  Is there a reason
> these calls are this way and if not we might consider switching them.  I have
> just tested this a small amount now so there might be some lurking issue under
> the hood, but I thought I might bring it up.
> 
> Andy

No particular reason. If something looks strange in the PETSc classes,
it probably is.

I just learnt earlier this week from Matt what MatSetFromOptions
actually does. I used to think it would override any options that we
set with either default options or command-line options. That's not
true. It only overrides options specified on the command-line so the
call to MatSetFromOptions should happen as late as possible, but
before the preallocation.

Anyway, I did a little reorganization. See if you like it. The PETSc
classes (PETScMatrix, PETScVector and PETScKrylovSolver) really need
some cleanup. They can be simplified and improved significantly. We
wrote them 4 years ago and haven't really touched them much since
then. I'll see if I can find time to do this at some point, but any
suggestions/patches are welcome.

Again, if something looks strange in the PETSc classes, it probably
is.

-- 
Anders