[petsc-dev] Support for projections in petsc solvers

[Alejandro Cosimo]

Because that's how the method is formulated, known as (Preconditioned)
Conjugate Projected Gradient. I think it would be good to keep the design
as close as possible to the actual formulation of the method.

2015-10-02 20:16 GMT+02:00 Barry Smith <bsmith at mcs.anl.gov>:

>
> > On Oct 2, 2015, at 2:23 AM, Alejandro Cosimo <alecosimo at gmail.com>
> wrote:
> >
> > Thanks Matt and Barry for the answer. Regarding the preconditioning. I
> have three steps which act successively on the residual, projection
> (w=P^T*r), preconditioning (z=M^{-1}*w) and re-projection (y=P*z). But all
> those steps can be interpreted as a single preconditioning step, mainly the
> application of P*M^{-1}*P^T on the residual. I can implement that inside my
> PCApply.
> >
> > Regarding the use of a new convergence test routine for checking on
> P^T*r for convergence: I think it could work, although it would be good to
> manage explicitly the projections inside the solver.
>
>    Why would it be "good to manage the projections inside the solver"?
>
>   Barry
>
> >
> > Regards,
> > Alejandro
> >
> > 2015-10-01 23:16 GMT+02:00 Barry Smith <bsmith at mcs.anl.gov>:
> >
> >     Do you mean  application of the precondition is     P*M^{-1}*P^T
> ApplyPC  P*M^{-1}*P^T  or something else?
> >
> >     If so then PCCOMPOSITE is not for this purpose in any way. You just
> need to  do all three things inside your PCApply.
> >
> >
> > > On Oct 1, 2015, at 4:38 AM, Alejandro Cosimo <alecosimo at gmail.com>
> wrote:
> > >
> > > Hello everybody,
> > >
> > > I'm interested in implementing FETI-1. Regardless of the iterative
> solver used for solving the interface problem, before applying the
> preconditioner it is required to project the residual and after applying
> the preconditioner to the projected residual to re-project again. It could
> seem that PCCOMPOSITE could be used in this case, performing the operation
> P*M^{-1}*P^T at once over the residual. However, this is not useful for the
> general case in FETI-1 because the convergence of the iterative solver must
> be checked with the projected residual, that is P^T*r, or in same cases
> with M^{-1}*P^T*r, but not with P*M^{-1}*P^T*r. That is why I would need
> support for projection and reprojection phases in petsc solvers.
> >
> >    As Matt said if you are checking on something like P^T*r for
> convergence then you do that with a new convergence test routine.
> >
> >    BTW: Maybe you could use the source of KSPCreate_FCG() as a starting
> point for a CG implementation that keeps a complete history.
> >
> >   Barry
> >
> > >
> > > Right now there is no support for that. So, my question: for
> implementing the support of the projection and reprojection phases in petsc
> I would introduce the functions ApplyProjection and ApplyReProjection to
> the petsc implementation in the same way that, for example, ApplyPC is
> supported. What do you think about this? Would you proceed like this?
> > >
> > > After implementing the support for ApplyProjection and
> ApplyReProjection, I would incorporate the behavior to one of the petsc
> iterative solvers. For that I would adopt the GMRES solver because it
> prevents me from implementing the full re-orthogonalization that is
> required when CG is adopted as iterative solver for FETI-1 (something which
> is not implemented in petsc CG). In that case, do you recommend me to
> define a new GMRES in petsc, or to modify the already exiting GMRES
> implementation by introducing the option of performing the phases of
> projection and reprojection?
> > >
> > > Regards,
> > > Alejandro
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20151002/b705bc1f/attachment.html>