> > (referring to your previous email about the kind of discretization) I'm > using P_2 finite elements on tetras. The mesh is so small that it might as > well be partitioned lexicographically (but in this case it was done by > Metis) >
Well, This seems fine. Higher order elements can confuse AMG sometimes but the math is decent in hypre and ML and I think it would be about the same with GAMG with the parameter that I gave you. Something is going wrong. We are trying to find it but not having any luck. There are many parameters, including stupid things like solver parameters and stupider things like bugs, that can kill an iterative solver and we are trying to figure out what is wrong here. You should be running with about 1/10 or 1/100, or even 1/1000, the number of processors that you are using here. If you eventually want to run in this regime then that is fine but for debugging it helps to be in a more normal regime, because then you (or us) can start to see secondary things like super slow flop rates that can provide a hint of what is going wrong. It is also better to start in serial so there are less moving parts -- I have to think that these terrible ML and hypre setup times would go away in serial … not that that is a solution but it is knowledge. Also, keep in mind that MG is better at scaling so for small problems direct solvers or simple solvers can be faster. Also AMG has significant setup costs (but they should not be as high as you are seeing) and this pushes the "cross over" point higher if you are just looking at one solve. These costs are amortized for multiple solves but these are just the basic complexity issues with solvers. MG may not always win on Poisson but it should, just about always. Mark > Now that at least either GAMG or BoomerAMG are not stuck for small > matrices I'll try to go bigger, and hopefully won't have to bother you > again, thanks a lot for all your pointers. > > Pierre > > PS: about src/ksp/ksp/examples/tutorials/ex56.c, Dirichelet (line 6) > should read Dirichlet. Thanks,
