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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
