[petsc-users] Enquiry regarding log summary results

[Jed Brown]

Now most of the time is spent in PCApply, though an inordinate amount is
still in VecScatterEnd, indicating that either your partition is very bad
or the machine has contention (either with other jobs, zombie processes,
incorrect affinity, over-subscribed).

In any case, you can try changing the smoother. For example, try skipping
the Chebyshev iterations and just use one iteration of SOR...

On Fri, Oct 5, 2012 at 10:08 AM, TAY wee-beng <zonexo at gmail.com> wrote:

> On 4/10/2012 11:44 PM, Satish Balay wrote:
>
>> On Thu, 4 Oct 2012, Matthew Knepley wrote:
>>
>>  the Mom-Z solve is bad because the assembly of the operator is
>>> screwed up. You are communicating too many values. So, jsut go into
>>> your code and count how many off process entries you set.
>>>
>> running with '-info' should give debug info regarding this
>> communication [stack size used for messages, and the number of mallocs
>> needed etc..]
>>
>> Satish
>>
>
> Ok, I found my problem. I was using:
>
> PetscLogStage  stage
>
> and the time for the poisson eqn got combined into that of the momentum_z
> solve. Hence the confusion in results.
>
> I have attached the new results. The time is taken up mainly by GAMG. I am
> using:
>
> -poisson_pc_gamg_agg_nsmooths 1
> -poisson_pc_type gamg
>
> What are the possible ways to improve the efficiency or reduce the time?
>
> If I use HYPRE's geometric multigrid, performance is somewhat better, such
> that momentum_x/y/z accounts for a total of 15% computing time.
>
> From the log_summary, for the momentum eqns, it seems that MatAssembly is
> the main problem, is that so?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20121005/bc3a90a4/attachment-0001.html>