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