dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jan 15, 2007 at 06:38:07PM +0100, kent-and@xxxxxxxxx wrote:
> > On Mon, Jan 15, 2007 at 05:58:46PM +0100, Garth N. Wells wrote:
> >>
> >>
> >> Anders Logg wrote:
> >> > On Thu, Dec 07, 2006 at 01:12:41AM +0100, Garth N. Wells wrote:
> >> >
> >> >>>> I'll add shortly the possibility to run the Cuthill-McKee over the
> >> map
> >> >>>> and reorder it. This will be an option.
> >> >>> What is Cuthill-McKee?
> >> >> It's the most common reordering algorithm. It will probably improve
> >> the
> >> >> sparse matrix performance.
> >> >
> >> > How about using the Boost Graph Library for this?
> >> >
> >> >     http://www.boost.org/libs/graph/doc/table_of_contents.html
> >> >     http://www.boost.org/libs/graph/doc/cuthill_mckee_ordering.html
> >> >
> >> > We already have a boost dependence so another one is no problem.
> >> >
> >>
> >> Sure, if it's in Boost I'd much rather use it than implement it myself.
> >
> > I've started looking at it and might commit something tonight.
> >
> >> I will start with a class Assembler soon. This is related in some ways
> >> to DofMap, matrix layout, reuse, etc. We could then create a class
> >> "pAssembler" for experimental parallel assembly which should eventually
> >> merge back into Assembler.
> >>
> >> Garth
> >
> > I'm also about to start working on an Assembler class that works with
> > the UFC generated code. Should we work together on the new Assembler
> > class? Alternatively, I could open a separate UFCAssembler class (to
> > be merged)?
> >
> 
> Have you looked at the Martins (UFC) Assembler ? You should have
> a look at it. So far we have implemented the assembler for PyCC, stl-map, and
> Epetra matrices as well as a "matrix-free" matrices.
> We have planned to include dolfin and PETSc matrices as well but have not
> had the time to do it. It should not be hard.
> 
> Kent

Yes, but Martin's assembler is in PyCC so we can't use it. PyCC is
not yet free and DOLFIN can't depend on PyCC.

So we need to (re-)implement it in DOLFIN. It might seem silly to have
two implementations doing the same thing but I don't see any other
solution. The good thing might be that we'll be able to compare the
speed of the two assemblers which will help optimize both codes.

/Anders