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

[Jungho Lee]

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.

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130919/b5579a04/attachment.html>