[petsc-users] MatMatSolve for MUMPS disappeared?

[Alexander Grayver]

On 19.09.2012 13:17, Jed Brown wrote:
> On Wed, Sep 19, 2012 at 2:52 AM, Alexander Grayver 
> <agrayver at gfz-potsdam.de <mailto:agrayver at gfz-potsdam.de>> wrote:
>
>     Is MatSolve in any way more efficient than KSPSolve?
>     As far as I understand for both cases one ends up with a loop over
>     RHS,
>     but KSPSolve allows to use iterative solvers (I don't need them at
>     the moment though).
>     I would then use latter option and do this loop myself.
>
>
> The loop over KSPSolve configured with -ksp_type preonly -pc_type lu 
> will do the same thing as MatMatSolve_Basic. If you think you might 
> want to use iterative methods, this is definitely the way to go. 
> Adding support for block Krylov methods (that inherently handle 
> multiple right hand sides) is something we've been discussing for a 
> while and will eventually happen, but I can't promise a time.

Jed,

I will stick to that option then and implement that loop myself.
Thanks.

>     That is right. The request on that has recently appeared in the
>     mumps mailing list and they replied there are no plans to develop it.
>     I have usually < 10^3 and this is not a bottleneck, so I'm fine
>     with a "inefficient" loop over RHS.
>
>
> How large are the vectors? It's easy for a small number of right hand 
> sides to overflow memory on rank 0.

On the order of 10^6 so far.
I guess memory has never been a problem because internally PETSc used 
MatMatSolve_Basic for MatMatSolve with MUMPS. Thus you never gather more 
than one rhs.
>
>
>     But, for those who are chasing performance and have many sprase
>     RHS (e.g., this is the case when one needs to solve many adjoint
>     problems with delta function as a RHS) I can say that using MUMPS'
>     multiple RHS mode is a way more efficient than solving them in a
>     loop. This is probably related to some internals where MUMPS is
>     able to take advantage of getting many RHS at once.
>
>
> There are significant efficiencies to handling many RHS at once, but 
> even if the right hand sides are sparse, the solutions are dense. The 
> savings from doing special things for the sparse RHS are thus only 
> incremental.


-- 
Regards,
Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120919/74d4a0e5/attachment.html>