dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

Martin Sandve Alnæs wrote:
> On 1/15/07, Anders Logg <logg@xxxxxxxxx> wrote:
> > 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.
>
> I certainly wouldn't mind merging my Assembler with your efforts in Dolfin,
> but the new Assembler should be located in Dolfin like Anders argued.
>
> It does not have very strong dependencies on other parts of PyCC yet,
> so that shouldn't be a problem. I'm sure you wouldn't mind adding Epetra
> support to Dolfin either.
>
> But if we are to merge the projects it would be nice to know as soon as
> possible, to avoid wasting time on duplicated code.

I don't see a problem with two codes as it gives each project the 
freedom to pursue different interests/goals/visions. It gets complicated 
when a lot of developers get involved. It would/will be nice if/when 
PyCC is opened up so we can look at each others work, exchange ideas and 
code, and collaborate more.

Garth


> martin
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev