<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 15, 2014 at 9:50 AM, William Coirier <span dir="ltr"><<a href="mailto:William.Coirier@kratosdefense.com" target="_blank">William.Coirier@kratosdefense.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Matt:<br>
<br>
So if we use the ex5 from SNES, use default ksp/pc and size the problem big enough via the M,N, it should scale?<br></blockquote><div><br></div><div>There are several kinds of scaling. If you use a series of problems, and the default solvers (GMRES/BJacobi/ILU), the</div>
<div>operations will scale (VecAXPY, VecDot, MatMult, etc.), but the number of iterates will grow. If you use MG and GAMG,</div><div>the number of iterates will be constant, but the setup time for GAMG will not be as scalable as the rest. Here is a paper</div>
<div>where we talk about scalability of a real code, instead of the toy problems that most CS people use,</div><div><br></div><div> <a href="http://onlinelibrary.wiley.com/doi/10.1002/jgrb.50217/abstract">http://onlinelibrary.wiley.com/doi/10.1002/jgrb.50217/abstract</a></div>
<div> <a href="http://arxiv.org/abs/1308.5846">http://arxiv.org/abs/1308.5846</a></div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Just checking...<br>
________________________________<br>
From: Matthew Knepley [<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>]<br>
Sent: Saturday, March 15, 2014 9:15 AM<br>
To: William Coirier<br>
Cc: Karl Rupp; <a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a><br>
Subject: Re: [petsc-users] KSPSolve doesn't seem to scale. (Must be doing something wrong...)<br>
<br>
On Sat, Mar 15, 2014 at 9:08 AM, William Coirier <<a href="mailto:William.Coirier@kratosdefense.com">William.Coirier@kratosdefense.com</a><mailto:<a href="mailto:William.Coirier@kratosdefense.com">William.Coirier@kratosdefense.com</a>>> wrote:<br>
Thanks Karl. We'll check this out on different architectures. I appreciate your help!<br>
<br>
Related to all of this, is there an example code in the distribution that might be recommended to use for testing machines for scalabiilty? Perhaps an example from the KSP?<br>
<br>
SNES ex5 is a very simple code and easy to see what is happening on the architecture. I use it to start. You<br>
can increase the grid size using -da_grid_x M -da_grid_y N.<br>
<br>
Matt<br>
<br>
Thanks again...<br>
<br>
Bill C.<br>
________________________________________<br>
From: Karl Rupp [<a href="mailto:rupp@iue.tuwien.ac.at">rupp@iue.tuwien.ac.at</a><mailto:<a href="mailto:rupp@iue.tuwien.ac.at">rupp@iue.tuwien.ac.at</a>>]<br>
Sent: Saturday, March 15, 2014 4:01 AM<br>
To: William Coirier<br>
Cc: <a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a><mailto:<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a>><br>
Subject: Re: [petsc-users] KSPSolve doesn't seem to scale. (Must be doing something wrong...)<br>
<br>
Hi William,<br>
<br>
I couldn't find something really suspicious in the logs, so the lack of<br>
scalability may be due to hardware limitations. Did you run all MPI<br>
processes on the same machine? How many CPU sockets? If it is a<br>
single-socket machine, chances are good that you saturate the memory<br>
channels pretty well with one process already. With higher process<br>
counts the cache per process is reduced, thus reducing cache reuse. This<br>
is the only reasonable explanation why the execution time for VecMDot<br>
goes up from e.g. 7 seconds for one and two processes to about 24 for<br>
four and eight processes.<br>
<br>
I suggest you try to run the same code across multiple machines if<br>
possible, you should see better scalability there. Also, for<br>
benchmarking purposes try to replace the ILU preconditioner with e.g.<br>
Jacobi, this should give you better scalability (provided that the<br>
solver still converges, of course...)<br>
<br>
Best regards,<br>
Karli<br>
<br>
<br>
On 03/14/2014 10:45 PM, William Coirier wrote:<br>
> I've written a parallel, finite-volume, transient thermal conduction solver using PETSc primitives, and so far things have been going great. Comparisons to theory for a simple problem (transient conduction in a semi-infinite slab) looks good, but I'm not getting very good parallel scaling behavior with the KSP solver. Whether I use the default KSP/PC or other sensible combinations, the time spent in KSPSolve seems to not scale well at all.<br>
><br>
> I seem to have loaded up the problem well enough. The PETSc logging/profiling has been really useful for reworking various code segments, and right now, the bottleneck is KSPSolve, and I can't seem to figure out how to get it to scale properly.<br>
><br>
> I'm attaching output produced with -log_summary, -info, -ksp_view and -pc_view all specified on the command line for 1, 2, 4 and 8 processes.<br>
><br>
> If you guys have any suggestions, I'd definitely like to hear them! And I apologize in advance if I've done something stupid. All the documentation has been really helpful.<br>
><br>
> Thanks in advance...<br>
><br>
> Bill Coirier<br>
><br>
> --------------------------------------------------------------------------------------------------------------------<br>
><br>
> ***NOTICE*** This e-mail and/or the attached documents may contain technical data within the definition of the International Traffic in Arms Regulations and/or Export Administration Regulations, and are subject to the export control laws of the U.S. Government. Transfer of this data by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Department of State or Commerce, as applicable, is prohibited. No portion of this e-mail or its attachment(s) may be reproduced without written consent of Kratos Defense & Security Solutions, Inc. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you<br>
are not the intended recipient or believe that you may have received this document in error, please notify the sender and delete this e-mail and any attachments immediately.<br>
><br>
<br>
<br>
--------------------------------------------------------------------------------------------------------------------<br>
<br>
***NOTICE*** This e-mail and/or the attached documents may contain technical data within the definition of the International Traffic in Arms Regulations and/or Export Administration Regulations, and are subject to the export control laws of the U.S. Government. Transfer of this data by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Department of State or Commerce, as applicable, is prohibited. No portion of this e-mail or its attachment(s) may be reproduced without written consent of Kratos Defense & Security Solutions, Inc. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient or believe that you may have received this document in error, please notify the sender and delete this e-mail and any attachments immediately.<br>
<br>
<br>
<br>
--<br>
What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
<br>
--------------------------------------------------------------------------------------------------------------------<br>
<br>
***NOTICE*** This e-mail and/or the attached documents may contain technical data within the definition of the International Traffic in Arms Regulations and/or Export Administration Regulations, and are subject to the export control laws of the U.S. Government. Transfer of this data by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Department of State or Commerce, as applicable, is prohibited. No portion of this e-mail or its attachment(s) may be reproduced without written consent of Kratos Defense & Security Solutions, Inc. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient or believe that you may have received this document in error, please notify the sender and delete this e-mail and any attachments immediately.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>