On Tue, Jul 22, 2008 at 9:23 AM, Garth N. Wells <[EMAIL PROTECTED]> wrote: > I've been testing assembly with various back-ends, and the bottleneck is > std::map::insert(..). I don't see an easy away around this which would > yield the complete sparsity pattern. > > For various back-ends (PETSc, MTL4, and perhaps Trilinos), I would > suggest that we go back to how we initialised matrices before the > introduction of the sparsity pattern, where based on the number of > neighbours to each cell and the finite element dimension, the maximum > number of non-zeroes per row was estimated. With this information, there > is no time overhead in assembling PETSc and MTL4 matrices relative to > using the complete sparsity pattern. > > A more sophisticated but complex approach would be to allow FFC to help > compute the maximum number of non-zeroes. How hard would it be for FFC > to compute the maximum number of non-zeroes per row given the number of > neighbours of a mesh entity? Using FFC, it would be possible to take > into account the type of finite element.
I have this all written (in parallel, for lcoally renumbered meshes) in PETSc. You can check include/petscmesh.hh:preallocateOperator(). All the messiness comes from local renumbering. If you discount that, it is very easy. Matt > Garth > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
