← Back to team overview

dolfin team mailing list archive

Re: [HG dolfin] Use DofMap in FEM to get dof mapping and to compute number of nonzeroes per matrix row. This gives big memory savings for some problems. For /src/demo/pde/elasticity memory use was approx. 600mb, now 200mb.

 

On Mon, Jan 15, 2007 at 09:10:00PM +0100, Ola Skavhaug wrote:
> 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.

Something that might help is if everyone on the list could actually
look at the code and see what's in there. I can look at the code but
to everyone else, PyCC is just a mystery.

/Anders


Follow ups

References