[petsc-users] KSP convergence problem

[John Mousel]

Mark,

Right now, Mehrdad and I are just passing the constant vector. The problem
is that the null space is extremely expensive to compute. Something like
5-20 times the cost of solving the Poisson equation itself depending on the
problem size. What we have tried in the past is to find a single solution
to Atrans*n = 0 and pass this as the nullspace. It's had success at making
the true residual drop in unison with the preconditioned residual. However,
because we are working with moving boundary problems, the null space is
changing each time step. In order to get around this, we have decided to
try to avoid giving the null space, and see if we get an accurate answer,
and we do get pretty much the same answer when we only require
preconditioned residual convergence. This is obviously less than robust,
but we've yet to find a way to get the null space in an efficient manner. I
tried programming up a GASM type algorithm where BiCG/ILU is used near the
interface where the solution is not smooth, and GAMG is used far away where
the changes in the null vector are very very small, but that didn't have
much success.

John


On Wed, Mar 20, 2013 at 4:37 PM, Mark F. Adams <mark.adams at columbia.edu>wrote:

>
> On Mar 20, 2013, at 4:13 PM, Mehrdad H Farahani <mh.farahani at gmail.com>
> wrote:
>
> I am solving a Poisson equation with Neumann boundary conditions applied
> along an arbitrary curve using a ghost fluid treatment. The matrix is
> non-symmetric and the null space contains more than the constant vector. I
> have implemented a solve for the null space itself and have previously
> supplied it using MatSetNullSpace. Unfortunately the null space solve is
> extremely expensive and does not play well with GAMG or ML. We've checked
> that the answers we get without supplying this null space are very close to
> the answers
>
>
> If you set the null space in GAMG and (I'm sure) ML you need to give us he
> _whole_ null space.  For 3D elasticity GAMG will take coordinates and --
> just for user convenience and to annoy Jed -- we create the 6 rigid body
> modes.  How many null space vectors are you giving us?
>
> we get when we do include it. The matrix for the two solves in the
> previous attachment are identical. The problem also seems to be converging
> and then suddenly diverges. Is this common behavior for a singular
> preconditioner?
>
> Thanks,
>
>
>>
>> From: Jed Brown <jedbrown at mcs.anl.gov>
>> Date: Wed, Mar 20, 2013 at 2:03 PM
>> Subject: Re: [petsc-users] KSP convergence problem
>> To: PETSc users list <petsc-users at mcs.anl.gov>
>>
>>
>>  On Wed, Mar 20, 2013 at 2:00 PM, Mark F. Adams <mark.adams at columbia.edu>wrote:
>>
>>>
>>> On Mar 20, 2013, at 2:12 PM, Mehrdad H Farahani <mh.farahani at gmail.com>
>>> wrote:
>>>
>>> > I'm experience a weird convergence problem with bcgsl with both ILU
>>> and GAMG preconditioning. The problem converges normally (at least in the
>>> preconditioned norm), but then kicks out with converged reason = -4. I've
>>> attached the convergence history of the previous time-step which worked and
>>> the timestep which shows problems. Could someone give me an idea on how to
>>> proceed?
>>> >
>>>
>>> Did you run with -ksp_converged_reason ?
>>>
>>> I don't know were this -4 comes from.  Could this be from your code?
>>>
>>
>> Some people call KSPGetConvergedReason(), but then don't compare to the
>> enums and don't convert to a string using KSPConvergedReasons[reason].
>>
>>
>> http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/KSP/KSP_DIVERGED_DTOL.html
>>
>> The problem is likely that your preconditioner is singular. What sort of
>> problem are you solving?
>>
>>
>
>
> --
> Mehrdad
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130320/a3f45b05/attachment-0001.html>