dolfin team mailing list archive

[Robert C.Kirby <kirby@xxxxxxxxxxxxxxx>]

On Oct 26, 2004, at 8:45 AM, Matthew Knepley wrote:

> Robert Kirby <kirby@xxxxxxxxxxxxxxx> writes:
>        Wow, we are using the same word for really different things. In 
> this
> respect, email discussion really suck.
>
> > 1.) If this is true, why are we working on ferari?
>        My meaning has always been, interface is the information which 
> is
> provided, implementation is the method for encoding and using the 
> information.
> Thus, ferari and quadrature have the same interface (information), but 
> ferari's
> implementation computes that information much faster.

<< means much much faster than (less in time)
Of course ferari << quadrature, but if even quadrature << solver, why 
bother optimizing it?


> > 2.) Relative cost of assembly versus solve depends on:
> > 	- how good your sparse matrix implementation is
>         Yes, an implementation issue.
> > 	- how good your solvers are (e.g. Jacobi's method versus optimally 
> > preconditioned CG)
>         In my sense no, since this is rarely an implementation issues. 
> It is
>         a mathematical one having to do with the compatibility of 
> system and
>         solver.

Both/and.  First, there is the mathematical issue (this is tantamount 
and has the biggest impact).  But even if you have an optimal 
preconditioner, a crappy implementation of the matrix-vector product 
(e.g. (i,j) index storing by unsorted lists), you will have a huge 
difference in performance among implementations.

> > 3.) My point is that we are trying to optimize matrix assembly in its 
> > own right.  In order to do this, we need a linear
> > algebra package that assembles matrices as fast as possible.  In 
> > order to do this, it will need a coarser granularity
> > than "here's an entry, do something with it" -- The granularity of 
> > "Here is a local matrix and the global indices, put
> > them in" will afford a good library more opportunities to do better 
> > than inserting each item individually.
>         There is an interface issue, but a mundane one I think. It is 
> usually
> called "agglomeration" and is even found in Ian Foster's book on 
> parallel
> computing for kindergarteners. However, the bigger factor comes from 
> better
> implementation of the same interface.
Yes, but as you say in your response to Anders, you need an interface 
that is optimizable.  Setting values one at a time is not such an 
interface.