Derek,
Thanks for the reply. I would be very interested to read the paper, when it is published and so do keep me updated ! I already have options to run my code with -snes_mf and -snes_mf_operator so that a user specified preconditioner (the approximate Jacobian) like you mentioned is used. But from an efficiency perspective, for nonlinear problems, I was thinking may be a geometric multigrid algorithm would be competitive as compared to building a linearized version of the Jacobian and applying ILU or algebraic multigrid to solve it. From my initial studies, the ILU route does not seem to scale as I increase the number of processors and so the option to either use Geometric or Algebraic multigrid for elliptic-elliptic coupled systems seems attractive. I can use block-jacobi preconditioning, in which case each physics block is symmetric and here I can possibly use multigrid strategy. Also for incompressible flows, I can reduce the coupled equations to a pressure poisson and use multigrid again to precondition the physics block. Of course, I do not have any multi-grid support in my framework yet and so was wondering if there was a cleaner and elegant way to perform geometric multigrid. My main problem is that since mesh is associated with the EquationSystem, when I coarsen the mesh, all my systems are reinited and reallocated. And so it just seems too expensive to perform couple of cycles this way. If this is the only route to perform geometric multigrid, then I will settle for algebraic multigrid in which case I'll build the linearized Jacobian matrix for each physic and call hypre to precondition that. Now what do you suggest would be optimal based on the data-structures provided by LibMesh and petsc ? Ben, It is interesting that you mention the p-multigrid for fluid flow because I was also thinking of that as an option. But I have tried something like using a lower order upwinded flux to precondition a higher order DG discretization with Rusanov flux. Of course I've never compared the efficiency of this scheme to any alternate methods and so, it is still up for debate on how good this idea is. Anyway, thanks for the ideas till now guys. I am still working on installing hypre with petsc and configuring that with libmesh. And once I am done with that, I'll try algebraic multigrid and then compare to traditional preconditioning methods. In the meanwhile, if you have suggestions to perform geometric multigrid, do let me know. Thanks, Vijay _____ From: Derek Gaston [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2008 4:49 PM To: Vijay M Cc: Roy Stogner; [email protected] Subject: Re: [Libmesh-users] Multigrid techniques with libmesh We're currently working on some papers in this area... but I don't have anything to share yet. Here's what I will say. If you are using a matrix or jacobian free method and you specify your residual correctly... then (in theory) you will get the right answer (eventually....). In reality, you're using a Krylov method... and we all know that those aren't going anywhere without some preconditioning. With libMesh and Petsc (and Trilinos... eventually) you can fill in the Jacobian matrix (by specifying a compute_jacobian() function) and even if you are solving matrix free... you can precondition what's in the Jacobian matrix and use the result to precondition your matrix free solve. Look at example19. Note that there are both compute_residual() and compute_jacobian() functions that are attached to the non-linear solver. By default example19 will solve in a pure matrix free manner (the same as specifying -snes_mf on the command-line)... but if you pass "-pre" on the command-line it will cause the jacobian matrix to get filled using compute_jacobian and that matrix will be preconditioned... and the result will be used to precondition the matrix free solve. This is equivalent to passing "-snes_mf_operator" on the command-line when using Petsc (if you look at the code you will see that indeed when using petsc that option is set when you pass "-pre"). Now.... like I mentioned earlier if your residual is correct.... you will get the right solution.... regardless of what you put into the jacobian.... right?? Well... the truth is tricky. It turns out that as long as you don't put something _wrong_ into the jacobian you will be good to go. But.... you don't necessarily have to put the exact _right_ thing either. There is some grey area here... and what works for one system of equations won't work for another. In general, if you put something resembling the true jacobian in there... it will greatly help your linear solves. So... back to multigrid. It doesn't like non-symmetric operators right? So just don't put any into your jacobian! Essentially, you'll just be preconditioning the symmetric part of your problem... but this might be sufficient to get good convergence behavior. Note... this is just a suggestion.... you can dream up all kinds of things to put into the Jacobian............ I hope that helps, Derek On Sat, Nov 8, 2008 at 12:01 AM, Vijay M <[EMAIL PROTECTED]> wrote: Derek, My Jacobian is very much unsymmetric and so I am curious based on what Roy suggests. If the BoomerAMG does not work with unsymmetric systems, this could be a problem. When you get back, please do detail on your findings and I would be very much interested to know about your experiences. Thanks. Vijay > -----Original Message----- > From: Roy Stogner [mailto:[EMAIL PROTECTED] > Sent: Friday, November 07, 2008 9:48 PM > To: Derek Gaston > Cc: [email protected] > Subject: Re: [Libmesh-users] Multigrid techniques with libmesh > > > On Fri, 7 Nov 2008, Derek Gaston wrote: > > > The answer to #2 is YES... We use Hypre with BoomerAMG to precondition > > our matrix free solves all the time. Just build petsc with Hypre > > support and pass the following on the command-line for your app: > > > > -snes_mf_operator -pc_type hypre -pc_hypre_type boomeramg > > > > This will use AMG on whatever you put into the jacobian matrix and use > > the result to precondition your matrix free solve. > > Wait - run that by me again? > > "matrix free solves" ... "use AMG on whatever you put into the > jacobian matrix" ... > > Wouldn't that make it an "AMG free solve"? > > But seriously, how is AMG possible without a matrix to work with? > > Also: do you have BoomerAMG working on asymmetric problems? It was > giving us real trouble (like, converging to the wrong result trouble) > a couple years back when we tried to use it on a problem with an > asymmetric jacobian. > --- > Roy > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100 <http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/ > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
