Stefano, I've looked at ksp/ksp/examples/tutorial/ex56 and the modification that I make to emin and emax seem to be essential and very useful, respectively. But I am seeing something funny with Cheb.
Jed: I'm seeing very little difference in convergence rates on ex56 when I use a first, second or fourth order Cheb smoother. I've seen some cases where the final residual was slightly larger with a higher order smoother. I think there is something wrong here ... Also, I thought we had added something like -pc_mg_smooth to set the number of smoothing steps when you are using the same smoother for the up and down smoother. I can not see a command for this. I did '-help | grep smooth', and I tried a few things. So to test this you need to manually fix the smoothing steps at about line 662 in gamg.c. Mark On Dec 3, 2011, at 1:03 PM, Stefano Zampini wrote: > Mark, > > I observe some strange behaviour in your gamg code: it always consider SA > method either if I pass "-pc_gamg_type geo" by command line or using > PCGAMGSetSolverType directly into my code. I put a printf of your variables > m_type and m_method inside gamg.c and it always prints m_type="string I've > passed" and m_method=2. > > I added some code into gamg.c for setting KSP and PC for the smoother. I > removed the define PETSC_GAMG_SMOOTHER and pass the correct value for PC to > createProlongation function. Is this enough to mantain self-consistency of > the code? > > Early test cases suggest better convergenge rate by dropping the lines where > you adapt emax and emin before their estimation, either with chebichev, or > with richardson (using richardson factor 2/(emin+emax)) > > Moreover, if I call PCSetCoordinates with dim=3 it prints an error reporting > "3d unsupported". > > Regards, > Stefano > > 2011/11/30 Mark F. Adams <mark.adams at columbia.edu> > Stefano, > > You really need to tell a black/gray box AMG solver that you are solving a > vector/step PDE. For GAMG you simply have to set the block size: > > ierr = MatSetBlockSize( mat, 2 or 3 ); CHKERRQ(ierr); > > I'm not sure if HYPRE or ML is equipped to deal with this in the PETSc > interface (I know the ML library can). > > ML and GAMG use smoothed aggregation which is well suited for elasticity but > to be optimal it needs the null space of the operator which is the 3 or 6 > rigid body modes for elasticity. GAMG has an interface where you can give it > the coordinates of your vertices and it will create the rotation rigid body > modes with this. If you do not give it coordinates then it will use only the > translational RBMs and, in general, will not be as good but still a usable > solver. > > Mark > > On Nov 30, 2011, at 12:25 PM, Stefano Zampini wrote: > > > Hi, > > > > I'm trying different AMG (sequential) solvers as black-boxes > > preconditioners for almost incompressible elasticity in 3d with spectral > > elements; specifically, ML and HYPRE (both called from PETSc), but they > > don't provide good results (at least using them via the PETSc interface). I > > wish to test for new GAMG preconditioner from actual petsc-dev. > > > > I wish to test the solver either with essential boundary conditions on one > > face, or with pure neumann boundaries. Can you (I think Mark Adams is the > > one I'm talking with) give my some hints on the customization of the > > preconditioner? > > > > Regards, > > -- > > Stefano > > > > > -- > Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111225/3427ecc0/attachment.html>
