[Users] logic of scheduling SelectBoundConds in McLachlan?

[Ian Hinder]

On 19 Feb 2013, at 19:19, Erik Schnetter <schnetter at cct.lsu.edu> wrote:

> Bernard
> 
> Did you set the parameters that Ian Hinder suggested? This will make interpreting the timing output much easier.
> 
> Time is not only spent in routines, but also in infrastructure tasks not listed here (regridding etc.). Ian Hinder implemented a tree-form timer output that makes it much easier to see how much time is spent on what task. I don't recall the options to select this -- Ian, is this Carpet::output_timer_tree_every and friends?

Yes.  That one displays the timer tree of the current process to standard output, and is useful for a quick overview.  I recommend enabling it in all simulations.  Unfortunately, it doesn't do a reduction across processes.  You can also output the top N timers, not in tree form, using n_top_timers; these *are* reduced across processes, but because many of the timers overlap (e.g. some timers contain other timers), it is harder to get a good overview.  You can also output an XML file per process containing the full hierarchical timer tree, which you can process in some other tool to do the reduction across processes (I have code in Mathematica to do this, if you are interested).

Ideally, I would like the stdout timer tree to include reductions across processes (min/max/average), and to have a version of the XML output which was also similarly reduced.  The reason this was not easy to do was that you could have different timers existing on each process, so some reductions wouldn't work.  It might be that this is no longer the case, and that implementing the reductions would be more straightforward now.  Erik?

> 
> -erik
> 
> 
> On Mon, Feb 18, 2013 at 2:59 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] <bernard.j.kelly at nasa.gov> wrote:
> Hi Roland, and thanks for your reply. I'm still a bit confused, I confess
> (see below) ...
> 
> On 2/16/13 12:38 AM, "Roland Haas" <roland.haas at physics.gatech.edu> wrote:
> 
> >Hello Bernard,
> >
> >> Hi. Can someone explain to me why ML_BSSN calls SelectBoundConds within
> >> MoL_PostStep? It seems like the kind of once-off routine that would
> >>happen
> >> near the start of a simulation, rather than something that has to be
> >> performed every single timestep.
> >In the "new" boundary/symmetry interface (ie using thorn Boundary and
> >Symbase) one has to Select the variables for boundaries each time before
> >ApplyBCs is scheduled. There is a routine in Boundaries that clears the
> >selection.
> 
> OK; but can you tell me *why* this is? Why should we ever have to
> re-specify what kind of boundary conditions we use during a simulation,
> any more than we re-specify the evolution equations? Perhaps I don't
> really understand what "select the variables" means here.
> 
> >
> >> I wouldn't mind, but while trying to understand why ML_BSSN was evolving
> >> so slowly on one of our machines, I looked at the TimerReport files, and
> >> saw that SelectBoundConds was taking *much* more time (like 20 times as
> >> long) than the actual RHS calculation routines.
> >The long time is most likely caused by the fact that the boundary
> >selection routine tends to be the one calling SYNC which means it is the
> >one that does an MPI wait (if there is load imbalance) and communicates
> >data for buffer zone prolongation etc.
> 
> So it might be spending most of the time waiting for other cores to catch
> up? But if it's really waiting for prior routines to finish on other
> processors, then on the handful of cores where SBC appears significantly
> *quicker* than usual (e.g. ~50,000 seconds instead of ~100,000) I should
> see earlier routines taking correspondingly *longer*, right? But I don't.
> 
> I'm attaching TimerReport files for two cores on the same (128-core)
> evolution. Core 000 is typical. Line 3591 (the most up-to-date instance of
> "large" SBC behaviour) shows about 100K seconds spent cumulatively over
> the simulation so far. Core 052 shows only about half as much time used in
> the same routine, but I can't see what other EVOL routines might be taking
> up the slack.
> 
> (Note, BTW, that what I'm running isn't vanilla ML_BSSN, but a locally
> modified version called MH_BSSN. The scheduling and most routines are
> almost identical to McLachlan)
> 
> Bernard
> 
> >
> >Yours,
> >Roland
> 
> 
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
> 
> 
> 
> 
> -- 
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.perimeterinstitute.ca/personal/eschnetter/
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20130219/06c0426f/attachment.html