dolfin team mailing list archive

[Robert Kirby <kirby@xxxxxxxxxxxxxxx>]

I will reply to the later discussion later.  But let me respond to the 
criteria Anders lists

On Oct 24, 2004, at 11:59 AM, Anders Logg wrote:

> 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.


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