From: Barry S. <bs...@mc...> - 2012-03-22 19:51:05
|
On Mar 22, 2012, at 2:42 PM, Roy Stogner wrote: > > 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? We've made this the default behavior in petsc-dev because too many people have wasted their time (like you had to) for misunderstandings of various types in preallocation. In the future users who wish to have incorrect preallocation must change the option after creating the matrix. Barry > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |