[petsc-dev] Should PETSc default to a different smoother than SOR for SBAIJ matrices with blocksize > 1?

[Barry Smith]

  Yeah the type is set in PCMGSetLevels() which is long before the operator on the various levels is even known. 

  Jed would fix this by having a PCAddPreferedType() so one could list multiple multiple preconditioners and then when the beast is actually to be used it picks the first one in the list that is supported by the information it has. So for example PCMGSetLevels() would call PCSetPreferedType(pc,PCSOR); PCSetPreferedType(pc,PCJACOBI); and at PCSetUp() time it would check the matrix to determine which one it could use.

  Barry would fix this by implementing the SOR for the block size you need in SeqSBAIJ and then Jed would complain that Barry didn't use horrific CPP ## code to automatically generate the code for all block sizes. Note also there is nothing inherently difficult about coding SOR for SBAIJ, just laziness.

  No one would want to make Jacobi the default all the time just because SOR is not supported for certain block sizes.

  Note that you should be able to run that example with -mat_type baij or -mat_type aij and have it run successfully with the default MG options.

   Of, of course you could run with -mg_levels_pc_type jacobi and the default sbaij matrices


   Barry



> On May 8, 2016, at 5:26 PM, Richard Mills <richardtmills at gmail.com> wrote:
> 
> Hi Folks,
> 
> Maybe I'm doing something wrong because I'm not that familiar with the current workings of multigrid in PETSc, but I was playing with Jed's SNES ex48 tutorial example (hydrostatic ice sheet flow), and was puzzled to find that trying to run a very simple variation:
> 
> ./ex48 -da_refine 1 -pc_type mg
> 
> results in a failure.  The problem appears to be that PETSc defaults to an SOR smoother, but symmetric SOR isn't implemented for the SBAIJ matrices (with block size > 1) that ex48 uses:
> 
> [0]PETSC ERROR: No support for this operation for this object type
> [0]PETSC ERROR: SSOR for block size > 1 is not yet implemented
> 
> Is this the desired behavior, or should PETSc default to a smoother like Jacobi that is implemented for this matrix type?
> 
> --Richard
> 
> P.S. Jed, if I just want to take the default problem and scale it up in size (for some simple parallel performance tests), is using -da_refine <some number> and a Jacobi smoother for the various levels reasonable?  Or do I need to do something more sophisticated?  (Sorry if this requires another thread.)