Take the 2-minute tour ×
Computational Science Stack Exchange is a question and answer site for scientists using computers to solve scientific problems. It's 100% free, no registration required.

I implemented a Navier Stokes based on FEM discretization and PETSc for solving the linear system of equations. To create an efficient solution procedure, I follow the paper "Efficient preconditioning of the linearized Navier-Stokes equations for incompressible flow" (Silvester et al.), which propose a Schur complement approach. It works quite fine in the sense that I have a nearly constant number of iterations independently of mesh size and timestep for the simple benchmarks that are also presented in this paper (2D driven cavity flow and backward facing step). But at the moment, I solve the upper velocity block with a parallel direct solver (MUMPS). The pressure Schur block is solved with inexact solvers as proposed in the paper.

In the paper, the authors propose to run in each outer iteration a single multigrid V-cycle and using a point Gauss-Seidel smoother to approximate the inverse of this discrete convection-diffusion operator. As I cannot easily use a geometric multigrid method, I thought to replace the direct solver by one algebraic multigrid V-cycle (boomeramg from the hypre package). But than I loose the constant number of iteratons while making the mesh finer.

Does any of you has an idea how to create a spectrally equivalent and efficient preconditioner for the inverse of the velocity matrices based on algebraic multigrid? Is there something inherent which does not allow to make use of algebraic multigrid in this case? If not, what could be the source of loosing the constant iteration scaling?


Edit:

I added some benchmarks for different solvers of the velocity block. The problem is solved is the standard 2D driven cavity flow, discretization with Taylor-Hood and a uniform refinement of the unit box

Exakt solver (MUMPS)

$h = \frac{1}{32}$: 25 iter $h = \frac{1}{64}$: 25 iter $h = \frac{1}{128}$: 25 iter $h = \frac{1}{256}$: 22 iter

one V-AMG (algebraic, boomeramg)

$h = \frac{1}{32}$: 30 iter $h = \frac{1}{64}$: 30 iter $h = \frac{1}{128}$: 39 iter $h = \frac{1}{256}$: 48 iter

FGMRES with preconditioner V-AMG (algebraic, boomeramg), rtol: $10^{-6}$

$h = \frac{1}{32}$: 30 iter $h = \frac{1}{64}$: 29 iter $h = \frac{1}{128}$: 30 iter $h = \frac{1}{256}$: 47 iter

FGMRES with preconditioner V-AMG (algebraic, boomeramg), atol: $10^{-8}$

$h = \frac{1}{32}$: 27 iter $h = \frac{1}{64}$: 27 iter $h = \frac{1}{128}$: 28 iter $h = \frac{1}{256}$: 26 iter

share|improve this question

1 Answer 1

up vote 2 down vote accepted

What you did is to replace the exact (direct) solver on the top left by one where you only do a single V-cycle. The way to go is to solve the top left block in your preconditioner using an iterative solver (e.g. GMRES) using the V-cycle AMG as a preconditioner to this inner solver. Experience shows that if you use F-GMRES as the outer solver, then the inner GMRES solver does not need to be terribly accurate. Just accurate enough to allow for it to yield an almost constant number of outer iterations.

share|improve this answer
    
I followed your suggestion and made some tests with replacing the exact solver by a fgmres (i think one has to use also the flexibal variante of gmres as the inner solver as multigrid should not behave as a linear operator) with V-AMG as a preconditioner. I added the results to my question above. As you see, when I replace the one V-cycle by a solver with relative tolerance, I get the same results. Only running the inner solver to a absolute tolerance makes the outer iteration constant to the price of increasing number of inner iterations. –  Thomas W. Oct 26 '12 at 6:20
    
I found the problem! Surprisingly, the problem was not due to a bad spectral approximation of the convection-diffusion operator, but to some mistake I made in the Schur complement part. So, even one V-cycle is fine for the velocity block and the solver requires 10 iteration per timestep independently of the mesh size. –  Thomas W. Oct 26 '12 at 11:19
    
Glad to hear. Your results are certainly in line with our experience in paper 35 here: math.tamu.edu/~bangerth/publications.html#x-reviewed –  Wolfgang Bangerth Oct 26 '12 at 12:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.