[petsc-dev] coarse grid in gamg (for the OPTE paper)

[Barry Smith]

On Sep 19, 2013, at 3:17 PM, Dmitry Karpeyev <dkarpeev at gmail.com> wrote:

> 
> 
> 
> On Thu, Sep 19, 2013 at 1:28 PM, Jungho Lee <julee at mcs.anl.gov> wrote:
> To fill others in on the situation here; this was regarding a variational inequality example, that uses reduced space method for which routines are defined in src/snes/impls/vi/rs/virs.c.  When MatGetSubMatrix was called to extract rows and columns of the original matrix corresponding to the "inactive" indices, original information about the block size wasn't copied.
> 
> KSP performance (with fgmres and gmres) deteriorates dramatically when I switch from mg to gamg (with agg), which I think is due to the lack of mechanism in gamg to take inactive/active indices into consideration for examples like this. 
> Wouldn't gamg work with the submatrix of only inactive degrees of freedom -- the jac_inact_inact in KSPSetOperators(snes->ksp,jac_inact_inact,prejac_inact_inact,flg) of SNESSolve_VINEWTONRSLS()?

   That is what it is doing and apparently it doesn't result in a good preconditioner; I don't know why off hand. One thing is it no longer knows about the block structure.

   Barry

>  
> 
> There is DMSetVI in virs.c, which marks snes->dm as being associated with VI and  makes it call an appropriate versions of coarsen (and createinterpolation, etc.,) which takes inactive IS into account, which in turn gets called in PCSetUp_MG. This part of PCSetUP_MG is skipped when gamg is used since it employs its own algorithm to figure out the coarse grid. So I think a possible solution is to provide a similar mechanism for gamg as well - but how?.
> 
> Ideas?
> 
> On Wed, Sep 18, 2013 at 9:11 PM, Mark F. Adams <mfadams at lbl.gov> wrote:
> >>> results in two levels with the coarse problem being 13*13. Wouldn't
> >>> it be natural for the coarse problem to be of size that's an integer
> >>> multiple of 3, though?
> 
> Yes, something is wrong here.  And as Jed said if you have different Mats for the operator and preconditioner the you have to set the block size on the preconditioned Mat.  If you are then we have a problem.
> 
> >
> >>> 2) For the specific set of parameters I'm using for testing purposes,
> >>> the smallest nonzero entry of the finest level matrix is of order
> >>> e-7.
> 
> BTW, the scaling of the matrix should not matter.  If you see a difference then we would want to look at it.
> 
> >>> For the coarse level matrix (size 13*13), whose entries are
> >>> determined by MatPtAP called in createlevel (in gamg.c), the smallest
> >>> nonzero entry is of order e-24 - this jumped out at me as a potential
> >>> sign of something wrong.
> 
> Oh, you are talking about the smallest.  That does not matter.  (its a sparse matrix so technically the smallest entry is zero)
> 
> 
>