dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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