* * * ##########################################################* * # #* * # WARNING!!! #* * # #* * # This code was compiled with a debugging option, #* * # To get timing results run ./configure #* * # using --with-debugging=no, the performance will #* * # be generally two or three times faster. #* * # #* * ##########################################################*
On Fri, Sep 14, 2012 at 6:08 PM, Zhenglun (Alan) Wei <zhenglun.wei at gmail.com > wrote: > I'm sorry about that. I attached the output files here with ' > -ksp_monitor -ksp_view -log_summary'. They are named after the grid size > and pc-type. > > cheers, > Alan > > On 9/14/2012 5:51 PM, Jed Brown wrote: > > On Fri, Sep 14, 2012 at 5:49 PM, Matthew Knepley <knepley at gmail.com>wrote: > >> On Fri, Sep 14, 2012 at 5:40 PM, Zhenglun (Alan) Wei < >> zhenglun.wei at gmail.com> wrote: >> >>> Dear folks, >>> I did some test with -pc_type gamg with >>> /src/ksp/ksp/example/tutorial/ex45.c. It is not as good as default -pc_type >>> when my mesh (Cartisian) is 100*50*50; while it is a little bit better than >>> the default one when the mesh is 200*100*100. Therefore, I guess this type >>> of pc is good for larger problem. Is that ture? or is there any rule of >>> thumb for this type of preconditioner? BTW, I tested it with 8 processes. >>> >> >> When asking questions about convergence, always always ALWAYS send the >> output of -ksp_monitor -ksp_view. If >> you don't, we are just guessing blindly. >> > > And -log_summary because this is about performance. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120914/a39f143d/attachment.html>
