[petsc-dev] new P^1.5 algorithm in VecAssembleBegin?

Mark Adams mfadams at lbl.gov
Fri May 29 14:39:49 CDT 2015


On Fri, May 29, 2015 at 3:29 PM, Jed Brown <jed at jedbrown.org> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>
> >   I cannot explain why the load balance would be 1.0 unless, by
> >   unlikely coincidence on the 248 different calls to the function
> >   different processes are the ones waiting so that the sum of the
> >   waits on different processes matches over the 248 calls. Possible
> >   but
>
> Uh, it's the same reason VecNorm often shows significant load imbalance.
>
> >> I've added a barrier in the code.
> >
> >    You don't need a barrier.  If you do not have a barrier you should
> >    see all the "wait time" now accumulate somewhere later in the code
> >    at the next reduction after the VecAssemblyBegin/End.
>
> Presumably he added a barrier *before* calling the function.  The
> function does a small amount of work (basically none because he has no
> off-process entries) and synchronizes (PetscMaxSum).  If there was load
> imbalance before calling VecAssemblyBegin, the timer would start at
> different times on each process, but end at about the same time.
>

Yea, I realized that VecAssembly should see this load imbalance unless it
had a barrier before its timer.  So I'm not sure what is going on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150529/c1b968bb/attachment.html>


More information about the petsc-dev mailing list