[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