[petsc-dev] sor smoothers
Barry Smith
bsmith at mcs.anl.gov
Mon Sep 9 15:07:25 CDT 2013
On Sep 9, 2013, at 3:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Barry Smith <bsmith at mcs.anl.gov> writes:
>> I don't see the advantage of keeping the PCMGSetResidual. It seems
>> to me that using the Amat to properly manage the different operator
>> approximations is the clean right way to do it. Messing with shoving
>> a random residual computer function seems prone to errors and
>> confusion about what operator is what. So is there a particular
>> case where using the hierarchy of Amat and Pmat won't work but
>> PCMGSetResidual will?
>
> Suppose the user is doing geometric multigrid with defect correction
> (high order residual, low-order correction) where the low order thing is
> Galerkin and the high-order is an expensive matrix-free
> rediscretization. The PCMG Galerkin code currently only handles when
> Amat and Pmat are the same on coarse levels, so where would the user put
> the code for the high-order residual?
How about fixing this? Agreed we should not be requiring people to use MatShell to do this stuff but it sounds you want to work around a current design flaw with PCMG by using PCMGSetResidual. Why not fix the design flaw?
Barry
>
> It's not that we can't provide directions to work around this (create
> MatShells, set their residual, and put them on appropriate levels, then
> make sure that PCSetUp_MG does not overwrite Amat on coarse levels), but
> I don't see PCMGSetResidual as being expensive for us to maintain and it
> fits a lot of folks' mental picture of how matrix-free MG works. What
> is the tangible value in deleting it (and breaking folks' code)?
More information about the petsc-dev
mailing list