[PETSC #14656] "multivector" support in PETSc?

[Barry Smith]

    The biggest reason we haven't added "multi-vectors" is more design
decisions that have to be made then actual code implementation. There 
are two important design decisions:

I) Introduce a new class or overload Vec?

    1) Introduce a Vecs class, essentially copying the interface from
       Vec and implement the methods. A Vecs is essentially a collection of Vec.
       Then provide methods such as
       MatMults(), MatSolves(), PCApplys(), PCSetUps(), KSPSolves() etc

    2) Overload the current Vec class so that a Vec is either a "regular"
       Vec or a collection of vectors. Modify the Vec interface and methods
       as needed, then modify the MatMult() etc as needed

    3) Do 1) and have it all working well and then use this to quickly
       do 2) and throw away the seperate concept of Vecs (without losing
       the fastest possible performance for a "new" Vec that has a single
       vector).

    The advantage of 1) is we never break the current interface. 2) has the
    advantage of not introducing a new class; and since software
    comprehension difficulty grows exponentially with the number of classes
    this is a good thing. The advantage of 3) is we get an incremental approach
    to 2) (incremental is often good). Disadvantage of 3) is that users have
    to live with first the Vecs interface (but on the other hand most people
    won't use Vecs anyways) and then go back to Vec.

    I think 3) is the correct approach.

II) Default storage of "multivectors"? (note: the interfaces for Vecs will, of
     course, be data storage format neutral, but the code we actually write
     cannot be)

    1) Have the Vecs be essentially an array of Vec.

    2) Have a Vecs essentially be a double array where the "values" of the
       "vectors" are interlaced.

    The advantage of 1) is that it is easier to implement and doing things
    like deflation (removing one of the vectors in a Vec) doesn't require
    any copies of the vector data. The advantage of 2) is better performance,
    and since we are using block for better performance we should take advantage
    of the best possible performance.

    I think implementing both 1) and 2) is appropriate, starting with 1) since
    getting it completed would be faster.

    Barry

Note: the Vecs currently in petscvec.h is just a toy and can be ignored.

On Fri, 7 Apr 2006, Victor Eijkhout wrote:

> The question has come up before. If all goes according to plan, then Bill 
> Gropp will hire a student for the summer to implement it. On a project that I 
> lead, and that has use for multivectors for a different purpose, there is 
> actually budget. Feel free to recommend someone to Bill if you know of a good 
> candidate. Does your former advisor have students who are familiar with the 
> matter?
>
> Victor.
>
> On Apr 7, 2006, at 1:05 PM, Richard Tran Mills wrote:
>
>> Hi Guys,
>> 
>> My former Ph.D. advisor, Andreas Stathopoulos (andreas at cs.wm.edu), has 
>> released an eigensolver package, PRIMME, that he is interested in 
>> interfacing as an external package with PETSc.  I told him a bit about how 
>> he could do this, but what I couldn't really answer was his questions about 
>> "multivector" support in PETSc.  PRIMME implements block 
>> Davidson/Jacobi-Davidson type methods, and thus needs to do a lot of 
>> operations like sparse matrix-multivector multiplies.  I haven't seen 
>> anything like this in PETSc (and since PETSc doesn't have block Krylov 
>> solvers, I suppose there is currently no need).  Has anyone done any work 
>> on stuff like this, or does anyone have any plans to?  Any thoughts on 
>> this?
>> 
>> Cheers,
>> Richard
>> 
>
>