On Dec 3, 2011, at 12:56 PM, Mark F. Adams wrote: > > On Dec 3, 2011, at 12: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. > > If you do not give it coordinates then it can not do geo. So I silently > switch it to SA with this: > > if(a_coords==0 && pc_gamg->m_method==0) pc_gamg->m_method = 2; /* use SA if > no coords */ > > Maybe I should throw and error here instead of silently switching ...
Yes, if they ask for something that cannot work you really need to error out. It is totally confusing to switch to something they didn't ask for. Barry > > It sounds like you hit this code. > >> >> 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? >> > > Cheby with diagonal preconditioning is a good default and I want to reuse the > eigen estimate for the prolongator smoothing. So instead of just setting the > PC type to Cheby, I should add PCSetFromOptions and then check if it is still > Cheby before computing the eigen estimate, and check that the PC is still > Jacobi before caching the max eigenvalue for reuse. Currently we can only > smooth the prolongation matrix with Jacobi easily. So the only > self-consistancy issue is in reusing the eigen estimate. > >> 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)) >> > > Not sure what you mean by "adapt emax and emin before their estimation", but > setting the Cheby emax and emin is full of heuristics and it can be tuned > better for any particular problem. If there is a big difference then that is > an issue for concern. > > 1) It is very bad if emax is lower than the true max eigen value so I bump up > the estimate some. The less you bump up, the better performance until you > get too low, then it dies rapidly. > > 2) The lowest eigen estimate is really a black art. Jed has suggested some > heuristics that might be better than what I now have. Fortunately > performance is not too sensitivity to emin (the cheby poly is pretty smooth > there). But this can be tuned to improve performance for any problem, I just > tuned it approximately with a few of the test cases (ex54, ex55, ex56). > > 3) One iteration of your richardson with factor 2/(emin+emax) is equivalent > to some first order cheby and so this is another type of parameter > optimization. NB, the lowest eigen estimate is very bad, too high for SPD > problems, from just a few iteration of a Krylov method. > >> Moreover, if I call PCSetCoordinates with dim=3 it prints an error reporting >> "3d unsupported". >> > > This sounds like you were trying to use 'geo' in 3D. I've added (not pushed) > "for 'geo' AMG" to this error message: > > SETERRQ(wcomm,PETSC_ERR_LIB,"3D not implemented for 'geo' AMG"); > > I do not fix this problem silently like I do the no coordinates case, I will > add that to my next push. > > Mark > >> 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 >
