Did you know that MatAssemblyBegin/End() wipes any not-already-assembled entries from the matrix, forcing them to be reallocated if they're part of a future assembly? Nice optimization in most cases, but I wish I knew how to turn it off.
Anyway... I just wasted an hour or two trying to debug such a preallocation failure in a PETSc-linked code; in hindsight that might have been reduced to a few minutes if only I'd known from the start that it was a preallocation failure. Should we turn on MAT_NEW_NONZERO_ALLOCATION_ERR by default in our PetscMatrix objects (at least the AIJ/BAIJ ones), either all the time or when we're in debug/devel modes? On the one hand, I can imagine people wanting to expand their matrices beyond the DofMap-allocated sparsity pattern, and it seems crude to prevent that or to require them to jump through solver-package-specific hoops first. On the other hand, PETSc (understandably) makes such expansion *really* slow, so anyone doing it is almost certainly making an inadvertent mistake. --- Roy ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
