[SciPy-dev] the current state and future directions of the sparse solvers

[Nils Wagner]

On Tue, 8 Apr 2008 22:46:34 +0200
  "Ondrej Certik" <ondrej@certik.cz> wrote:
> Hi Nathan!
> 
> On Tue, Apr 8, 2008 at 10:22 PM, Nathan Bell 
><wnbell@gmail.com> wrote:
>> On Mon, Apr 7, 2008 at 12:55 PM, Ondrej Certik 
>><ondrej@certik.cz> wrote:
>>
>>  Sorry for the late reply, I'm a little busy at the 
>>moment.
> 
> Thanks for the reply. I am quite busy too at the moment. 
>:)
> 
>>  >  2) why was pysparse removed? are there any 
>>objections of adding it
>>  >  among arpack and lobpcg solvers?
>>
>>  If I'm not mistaken, pysparse lived in the sandbox and 
>>the core
>>  functionality has largely been replaced/superceeded by 
>>that in
>>  scipy.sparse.
>>
>>  I have no opposition to reintroducing pysparse solvers 
>>that are
>>  missing in scipy.sparse, provided that someone is 
>>willing to maintain
>>  them.
> 
> OK, thanks, I am willing to maintain it. I'll try to 
>substitute it
> with the scipy solvers and if I find that pyspare has 
>some advantages,
> I'll prepare a patch.
> 
>>  >  3) sometimes I also use blzpack - are there any 
>>objections if I
>>  >  implement it (if I find time of course) the same way 
>>lobpcg and arpack
>>  >  is in there?
>>
>>  I'm not familiar with blzpack, but I don't see any 
>>reason to prohibit
>>  it (assuming it's compatible with the BSD).
> 
> Yes, it's BSD.
> 
>>  >  4) I would love to see all available open source 
>>sparse solvers and
>>  >  eigensolvers to be callable from scipy. Is this the 
>>intention of
>>  >  scipy.sparse?
>>
>>  Supporting a common interface to the various solvers 
>>would be quite
>>  useful.  However, like (2) we should not support 
>>interfaces to
>>  optional libraries/methods.
> 
> You mean support in scipy by default, right? I would 
>like to have the
> unified interface to all solvers (including petsc and 
>others).
> 
>>  >  Those are enough questions so far, depending on the 
>>answers, I'll
>>  >  probably have some more then, regarding the 
>>interface. :)
>>
>>  This is a valuable idea, however given the scope of the 
>>solvers you'd
>>  like to include, a scikit is more appropriate.  It 
>>would be very
>>  confusing to users that something under the scipy 
>>namespace required
>>  UMFPACK/PETSc/etc.  A scikit could support all these 
>>solvers while
>>  remaining self-contained.  I doubt it would require 
>>much time before
>>  such a scikit became a commonly-installed component. 
>> Furthermore,
>>  living outside SciPy would permit us to add 
>>functionality on a
>>  separate timetable.  As you've suggested, any 
>>functionality with an
>>  appropriate license (and sufficient appeal) could be 
>>moved to SciPy
>>  itself.
> 
> OK, that sounds very good. I am going to study how to 
>start such a
> scikit and we are going to move our additional solvers 
>we have in
> sfepy to it (pysparse, soon petsc4py) -- are you ok with 
>that Robert?
> :) Plus umfpack.  Plus the eigensolvers, like primme, 
>blzpack and
> others.
> 
AFAIK Jacobi-Davidson is part of pysparse.

And you probably know slepc

http://www.grycap.upv.es/slepc/

http://t2.unl.edu/documentation/slepc4py

And polyeig ... How about that ?

Cheers,

           Nils

For nonlinear eigenvalue problems, see

http://www.mims.manchester.ac.uk/research/numerical-analysis/nlevp.html