dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

I will make a comparison with PETSc (MatSetValuesBlocked(A,...,AK,...))
so we can see the exact difference. I think it is ok to use this type
of call within the assembler, but I would like to be able to use a
clean and simple OO interface elsewhere. (Looks like this is going to
be added to PETSc.)

We currently add the local element matrix AK to the global matrix A by doing

for (unsigned int i; ...)
    for (unsigned int j; ...)
        A(dof(i), dof(j)) += AK(i, j);

where dof() is the mapping from local to global degrees of freedom. Each
time we access the global matrix A on row dof(i), it has to search for
a nonzero entry in column dof(j) on that row so this is probably slow.
How do you avoid doing this search in PETSc? Or don't you?

/Anders

On Tue, Oct 26, 2004 at 07:36:26AM -0500, Robert Kirby wrote:
> 1.) If this is true, why are we working on ferari?
> 2.) Relative cost of assembly versus solve depends on:
> 	- how good your sparse matrix implementation is
> 	- how good your solvers are (e.g. Jacobi's method versus optimally 
> preconditioned CG)
> 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" 
> put them in" will afford a good library more opportunities to do better 
> than inserting each item individually.
> 
> Remember that Anders picked up a factor of 10 moving away from a naive 
> form interpreter to actual compiled code.  I wonder how much he will 
> pick up optimizing the matrix assembly
> 
> Robert C. Kirby
> Assistant Professor
> Department of Computer Science
> The University of Chicago
> http://people.cs.uchicago.edu/~kirby
> 
> On Oct 26, 2004, at 4:05 AM, Matthew Knepley wrote:
> 
> >ridg@xxxxxxxxxxxxxxx (Ridgway Scott) writes:
> >>How does the form of the API affect the efficiency of the linear
> >>algebra? It would seem that the overhead of the call would be
> >>small compared to the cost of doing a solve.
> >    This is true, and I think is the underpinning of Rob's argument.
> >
> >         Matt
> >>
> >>				Ridg
> 
>