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

[Dmitry Karpeyev]

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()?


>
> 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/2468c051/attachment.html>