dolfin team mailing list archive

[Johan Hoffman <hoffman@xxxxxxxxxxxxxxx>]

> > It's about time we came to a decision on the linear algebra of DOLFIN
> > (or FEniCS). This is not a poll, but your opinion might help us make
> > the correct decision.
> >
> > The current linear algebra of DOLFIN was implemented with simplicity
> > in mind, but it's not parallel and I don't think we have the time and
> > resources to maintain a complete linear algebra package of our own.
> >
> > There are a couple of different options we could consider:
> >
> > A1. Use an existing linear algebra package (see list below) as it is.
> >
> > A2. Use an existing linear algebra package, but create the appropriate
> > wrappers in DOLFIN (could just be a list of typedefs).
> >
> > A3. Develop and maintain an existing linear algebra package as a FEniCS
> > project.
>
> A1 is preferable, with A2 a distant second.  I see no circumstances under 
> which I would support A3.

At this stage I do not see that A3 is a competetive option. As for A1 or 
A2, it seems to depend on how easy we will be able to change package if we 
would want to, for any reason.

So maybe an alternative along the lines of Rob would be a good idea; FFC 
code generation directly to PetSc (for example), which should be 
maximally efficient, and a wrapper for the solver. This should then be 
easy to adapt to new packages; with a la-option in FFC, and a new wrapper 
for the solver?

/Johan

> I completely agree with B1 through B4.  However, I take exception to B5 for 
> the following reasons:
>
> 1.) Performance -- especially at the granularity of setting matrix values, we 
> want a low-level API to some C library -- hand it a double * and the int * 
> with indices and let it do the data structures as efficiently as it can.
> 2.) Why not C++?  First of all, PETSc (e.g.) is not *that* ugly, and besides, 
> our goal is to generate the fastest possible code.  It is easy for us to 
> write code that generates calls to the low-level API (we do it once and we're 
> done).  Performance is tantamount here, and generating C++ out of FFC will 
> almost always lead to slower code.  We don't have to settle for this.
> 3.) Of course, in the programming environment, we want some kind of 
> high-level handles for the matrices generated.  However, this can easily be 
> accomplished by wrappers.  So, if we were using PETSc (for example), we code 
> to the lower-level API when we generate code and allow application 
> programmers to use the high-level interface (since they don't care about 
> particular matrix entries anyway) to pass matrices to solvers in C++ or 
> Python.  It's all about granularity.
>
>
> > Whatever choice we make, the linear algebra package should satisfy the
> > following criteria:
> >
> > B1. It should be open-source.
>
> > B2. It should be standard or close to standard.
>
> > B3. It should be actively maintained.
> >
> > B4. It should be parallel.
>
>
>
> > B5. It should have a nice API (C++ style).
> >
> > Here's a list of available options. The list is not complete, but
> > it's a start:
> >
> > 1. PETSc: http://www-unix.mcs.anl.gov/petsc/petsc-2/
> >
> > Pros: Satisfies B1-4
> > Cons: Does not seem to satisfy B5. Maybe a future version of PETSc will?
> >
> > 2. MTL: http://www.osl.iu.edu/research/mtl/
> >
> > Pros: Satisfies B1 (?) and B5
> > Cons: Does not satisfy B2-4?
> >
> > 3. uBLAS: http://www.boost.org/libs/numeric/ublas/doc/index.htm
> >
> > Pros: Satisfies B1-3, B5
> > Cons: Does not satisfy B4
> >
> > 4. POOMA: http://www.codesourcery.com/pooma/
> >
> > Pros: ?
> > Cons: ?
> >
> > 5. Sparselib++: http://math.nist.gov/sparselib++/
> >
> > Pros: ?
> > Cons: ?
> >
> > 6. TNT: http://math.nist.gov/tnt/
> >
> > Pros: ?
> > Cons: ?
> >
> > 7. Blitz++: http://www.oonumerics.org/blitz/
> >
> > Pros: ?
> > Cons: ?
> >
> > /Anders
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev