dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

Anders Logg skrev den 15/01-2007 følgende:
> On Mon, Jan 15, 2007 at 08:10:12PM +0100, Ola Skavhaug wrote:
> > Anders Logg skrev den 15/01-2007 følgende:
> > > 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.
> > 
> > There is no problem opening the parts of PyCC that you need. Now, there is
> > only a question of time (and code quality) before PyCC is open.
> > 
> > Alternatively, we can split PyCC into a "core kernel" (or something
> > like that :), and rewrite the rest of PyCC such that it uses it. The
> > "core kernel" could be licenced any way we see fit.
> > 
> > Would this be of any help, or do you need a faster solution?
> 
> The relation DOLFIN <--> PyCC is problematic since both codes
> implement similar functionality in the same languages (C++ and Python)
> so a dependency from one to the other is not obvious.
> 
> PyCC currently depends on the DOLFIN mesh library so if DOLFIN were to
> depend on some part of PyCC, we'd have a circular dependency. I'd like
> the dependency graph to be directed and acyclic.
> 
> DOLFIN and PyCC would benefit from sharing more code but we need to
> figure out what roles the two codes have.

I agree. On one side, Dolfin provides low--level components like Mesh and
Vectors. On the other side Dolfin is also a high--level PSE. Similar goes for
PyCC (without the Mesh, of course). Let's have an open discussion. Things are
easier for us now, knowing PyCC can be opened soon. We can therefore be
flexible and adaptive with respect to your needs.

Ola
 
> /Anders