[Matrix-SIG] Sparse objects

John Turner turner@blueskystudios.com
Fri, 21 May 1999 12:11:31 -0400 (EDT)


>>>>> "HJ" == Henk Jansen <hjansen@math.tudelft.nl> writes:

>> But if I recall correctly, SPARSEKIT was one of the "researchy"
>> pkgs I alluded to in my previous msg that really only supported one
>> format internally (compressed sparse row, CSR, if I remember
>> correctly), and accomodated other formats by providing routines to
>> convert to and from CSR.

HJ> Yes, you're right, they only supported CSR and conversion routines
HJ> to and from it. I never realized (or, can't see) that "production"
HJ> code would require full (solver) support for all formats. Sparse
HJ> objects by their nature are lean and quickly convert into other
HJ> (sparse) objects. Is that penalty too high?

Memory is often a limiting factor in large, "real", 3-D simulations
(hundreds of thousands or millions of cells in an implicit flow
calculation, for example).  But maybe that's an inherently
inappropriate problem space for Python/NumPy.  I don't know...

Also "full support for all formats" really means a design such that
the solvers don't care about the storage format but instead just
implement the algorithm on "matrices" and "vectors", with those
things knowing how to do the appropriate operations.

As yet another twist, in many cases the actual coefficient is never
even constructed explicitly, either because it is too difficult or the 
problem is too large.  In this case the solver needs a routine to call 
to obtain the get the result of, e.g., multiplying some vector by the
coefficient.  This sort of "matrix-free" implementation is extremely
common.

My Fortran 90 package does all this in a nice object-based way, and as 
I've mentioned before represents the last in a series of evolutionary
implementations of sparse iterative solver libraries that I've done
over a number of years.  I'm sort of slow, so I had to do lots of bad
implementations along the way, but I think now I at least understand a 
lot of the issues.

I'd love to collaborate with someone who knows Python/NumPy better
than I do on the development of some sparse solver capability.  I know 
I'd learn a lot in the process, and maybe the community would gain a
useful tool as well.

-- 
John A. Turner, Ph.D.                Senior Research Associate
Blue Sky Studios                     http://www.blueskystudios.com/
One South Road, Harrison, NY 10528   http://www.lanl.gov/home/turner/
Phone: (914) 381-8400                http://john.turner.org/