[petsc-users] Tuning performance for simple solver

Matthew Knepley knepley at gmail.com
Fri Jun 3 07:32:22 CDT 2016


On Fri, Jun 3, 2016 at 5:56 AM, Dave May <dave.mayhem23 at gmail.com> wrote:

> On 3 June 2016 at 11:37, Michael Becker <
> Michael.Becker at physik.uni-giessen.de> wrote:
>
>> Dear all,
>>
>> I have a few questions regarding possible performance enhancements for
>> the PETSc solver I included in my project.
>>
>> It's a particle-in-cell plasma simulation written in C++, where Poisson's
>> equation needs to be solved repeatedly on every timestep.
>> The simulation domain is discretized using finite differences, so the
>> solver therefore needs to be able to efficiently solve the linear system A
>> x = b successively with changing b. The solution x of the previous timestep
>> is generally a good initial guess for the solution.
>>
>> I wrote a class PETScSolver that holds all PETSc objects and necessary
>> information about domain size and decomposition. To solve the linear
>> system, two arrays, 'phi' and 'charge', are passed to a member function
>> solve(), where they are copied to PETSc vectors, and KSPSolve() is called.
>> After convergence, the solution is then transferred again to the phi array
>> so that other program parts can use it.
>>
>> The matrix is created using DMDA. An array 'bound' is used to determine
>> whether a node is either a Dirichlet BC or holds a charge.
>>
>> I attached three files, petscsolver.h, petscsolver.cpp and main.cpp, that
>> contain a shortened version of the solver class and a set-up to initialize
>> and run a simple problem.
>>
>> Is there anything I can change to generally make the program run faster?
>>
>
> Before changing anything, you should profile your code to see where time
> is being spent.
>
> To that end, you should compile an optimized build of petsc, link it to
> you application and run your code with the option -log_summary. The
> -log_summary flag will generate a performance profile of specific
> functionality within petsc (KSPSolve, MatMult etc) so you can see where all
> the time is being spent.
>
> As a second round of profiling, you should consider registering specific
> functionality in your code you think is performance critical.
> You can do this using the function PetscLogStageRegister()
>
>
> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Profiling/PetscLogStageRegister.html
>
> Check out the examples listed at the bottom of this web page to see how to
> log stages. Once you've registered stages, these will appear in the report
> provided by -log_summary
>

Do everything Dave said. I will also note that since you are using FD, I am
guessing you are solving on a square. Then
you should really be using geometric MG. We support this through the DMDA
object.

  Thanks,

     Matt


> Thanks,
>   Dave
>
>
> And, since I'm rather unexperienced with KSP methods, how do I efficiently
>> choose PC and KSP? Just by testing every combination?
>> Would multigrid be a viable option as a pure solver (-ksp_type preonly)?
>>
>> Thanks,
>> Michael
>>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160603/3a5e7b1f/attachment.html>


More information about the petsc-users mailing list