[petsc-users] ML and linear elasticity

[Jed Brown]

Well, the KSP can diagonally scale it and we should fix up the near null
space. The PC should not need to find out about diagonal scaling. (My
opinion.)
On Apr 2, 2012 4:50 PM, "Mark F. Adams" <mark.adams at columbia.edu> wrote:

> Oh, OK, so you do not explicitly scale the matrix good.  We had a user
> (John) recently that was using diagonal scaling and was getting failure
> with GAMG and then GAMG worked and he was no longer using diagonal scaling
> so I was thinking this was the problem.
>
> Mark
>
> On Apr 2, 2012, at 7:40 PM, Barry Smith wrote:
>
> >
> >  Mark,
> >
> >   Who would be doing the "diagonal scaling". Under normal conditions we
> never want to be passing to any preconditioner a diagonally scaled matrix
> (for exactly the issue you point out) so why are you worried about that
> case?
> >
> >   Barry
> >
> > On Apr 2, 2012, at 6:40 PM, Mark F. Adams wrote:
> >
> >>
> >> On Apr 2, 2012, at 7:24 PM, Jed Brown wrote:
> >>
> >>> On Mon, Apr 2, 2012 at 07:44, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> >>> The block size is used if you don't provide any other information. The
> preferred approach with petsc-dev is to use MatSetNearNullSpace(). (I'll
> make sure this is currently working with ML and reply to this message.)
> >>>
> >>> I pushed ML support for user-provided null spaces to petsc-dev. Call
> MatSetNearNullSpace() to provide the information. You can use
> MatNullSpaceCreateRigidBody() if you have nodal coordinates.
> >>>
> >>>
> >>> Mark, what is the best way to make PCGAMG use this interface?
> >>
> >> It looks like you are adding this to the Mat, so I can check to see if
> coordinates have been set and if not check the matrix.  This should be easy
> to do; I'll look at the ML code to clone the API.
> >>
> >> One thing to keep in mind is that diagonal scaling breaks the null
> space (ie, the rigid body modes have to be scaled appropriately).  Who owns
> the diagonal scaling? If it is Mat then we might want MatSetNearNullSpace
> to do this, otherwise we should think of a good way to deal with this.  It
> is very error prone to not do the right thing here, we should at least
> throw an error.
> >>
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120402/e30f220d/attachment-0001.htm>