dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Tue, Jul 22, 2008 at 9:23 AM, Garth N. Wells <gnw20@xxxxxxxxx> 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
> DOLFIN-dev@xxxxxxxxxx
> 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