dolfin team mailing list archive

[Johan Hake <668862@xxxxxxxxxxxxxxxxxx>]

On Monday November 22 2010 14:41:06 Garth Wells wrote:
> On 22/11/10 22:28, Johan Hake wrote:
> > On Saturday November 20 2010 10:02:36 Garth Wells wrote:
> >> I've done some testing, and using unordered_set appears to not perform
> >> as well as Set for standard problems.
> > 
> > What are the differences in timing here?
> 
> I saw around a factor of 2. unordered_map also seems to use a lot more
> memory.

Ok.

> > The difference in timing using
> > unordered_set for Real spaces where dramatically better.
> > 
> >> Each dof (matrix row) has its own set. The sets are usually small, and
> >> independent of the mesh size. The problem is that the size of set that
> >> belongs to the global dof is equal to the number of columns in the
> >> matrix, and when looping over this set (which becomes very large)
> >> std::find is called a lot.
> > 
> > Is this true for any form? Why is this so notable when computing the
> > sparsity pattern when a subspace belongs to Real?
> 
> No, only forms with global dofs (like Real).

Does each row that is affected by the gobal dof become "full", due to the way 
the set is constructed, or is it just the row for the global dofs?

> >> I don't see simple solution from the SparsityPattern side. What's
> >> probably needed is an extension to UFC to distinguish between local and
> >> global dofs.
> > 
> > How would this help?
> 
> If we know that a dof is global, we can just insert it in the sparsity
> pattern for all cells. No need to perform a search (which is what get
> expensive for the 'Real' row, which is full).

That would be a nice feature!

Johan

> Garth
> 
> > Johan

-- 
Sparsity pattern computation dead slow with 'real' spaces
https://bugs.launchpad.net/bugs/668862
You received this bug notification because you are a member of DOLFIN
Team, which is subscribed to DOLFIN.

Status in DOLFIN: Confirmed

Bug description:
The computation of the sparsity pattern is dead slow when real spaces are used, i.e.,

    R = FunctionSpace(mesh, 'R', 0)

To see the problem, compare the neumann-poisson and poisson demos with fine meshes (256x256)