The custom residual makes sense now. I can find the residual itself in the same way my matrix application works and this should result in some savings..
Jed, thanks a ton for these detailed explanations. I think I understand enough to get going with this. If I hit a roadblock, I will post a question here. Thanks and have a great day. Vijay On Fri, Dec 3, 2010 at 2:16 PM, Jed Brown <jed at 59a2.org> wrote: > On Fri, Dec 3, 2010 at 21:09, Vijay S. Mahadevan <vijay.m at gmail.com> wrote: >> >> Ah, I misunderstood your explanation earlier. If I do provide the >> restriction/prolongation along with a fine-grid shell matrix and opt >> to not use Galerkin MG, then how do I provide the coarse grid >> operators to petsc? > > PCMGSetResidual() and PCMGGetSmoother() followed by KSPSetOperators(). > >> >> I also just remembered from one of your earlier >> posts that you mentioned the use of non-Galerkin coarse operators >> requires a coarse mesh to be provided. > > No, this is not required. PCMG's interface is purely algebraic, you do not > need to use DMMG or otherwise provide a "mesh". You have to provide > coarse-level operators (as described above). This is all in the users > manual. > >> >> And I dont quite get what a matrix-free residual is.. Wouldn?t >> PCMGDefaultResidual compute the residual with just MatMult operation >> defined (b-Ax) for every level ? Why do I need a custom residual >> operator ? > > If you have wrapped your coarse-level operator in MatShell, then you can > just pass that in and use PCMGDefaultResidual. Also from the users manual: > The residual() function can be set to be PCMGDefaultResidual() if one's > operator is stored in a Mat format. > In certain circumstances, where it is much cheaper to calculate the residual > directly, rather than through the > usual formula b - Ax, the user may wish to provide an alternative. > Jed
