On Sep 19, 2013, at 3:17 PM, Dmitry Karpeyev <[email protected]> wrote:
> > > > On Thu, Sep 19, 2013 at 1:28 PM, Jungho Lee <[email protected]> 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 <[email protected]> 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) > > >
