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