No subject

[Barry Smith]

   Yes, and eventually we'll want those variants generated automatically;
actually not that difficult. The difficulty is mostly in designing
a generator flexible enough but not so flexible it doesn't do anything :-)

    Barry

From: William Gropp <gropp at mcs.anl.gov>


> At 01:10 PM 4/8/2006, Barry Smith wrote:
>
>    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:

Thanks, Barry.  I agree with both of your suggestions.  For the second case
(storage ordering), in the long term, I might want to allow several forms
of interlacing and padding, depending on what testing shows provides a
significant performance boost.

Bill


>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
>>

William Gropp
http://www.mcs.anl.gov/~gropp