[Yt-dev] Proposed Halo Profiler Change

[Britton Smith]

Hi Matt,

I've just tried using Stephen's new recentering functions that use derived
quantities to halo profiling.  When running in parallel, there doesn't seem
to be a problem at all, whether I set lazy_reader to True or False.  I guess
there is no longer an issue here.

Britton

On Fri, Apr 8, 2011 at 3:22 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Britton,
>
> Do you think that changing to lazy_reader = False would fix the
> parallelism thing?
>
> But in general, this is another good reason to finish up the
> multilevel parallelism project, in the task_queue files.  I'm not sure
> what a reasonable timescale for that is, however.
>
> -Matt
>
> On Fri, Apr 8, 2011 at 12:03 PM, Britton Smith <brittonsmith at gmail.com>
> wrote:
> > Hi Stephen & Matt,
> >
> > I think Matt's idea is a good one.  It will be more work from the
> > development side to set up the functions, but I think it will be less
> > complicated and more flexible for the user.  The halo profiler already
> has
> > an embarrassingly large number of keyword options, so decreasing that
> number
> > is a good thing.
> >
> > While we're on the subject, I should mention that these recentering
> > functions will not work in parallel.  This is because the halo finder is
> set
> > up to run in parallel by giving a subset of halos to each processor and
> > essentially having each processor profile halos in serial.  However, the
> > derived quantities that are used for the recentering only know to work in
> > parallel by having all the processors work on the one halo.  What happens
> in
> > practice is that the job will just hang.  This is not totally relevant to
> > the discussion, but close enough that I thought it warranted being
> brought
> > up.
> >
> > Britton
> >
> > On Fri, Apr 8, 2011 at 11:55 AM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> >>
> >> Hi Stephen,
> >>
> >> It's simpler for the end user.  Instead of the end-user being mandated
> >> to supply a callable function, we should provide a couple recipes that
> >> they can supply as strings.
> >>
> >> -Matt
> >>
> >> On Fri, Apr 8, 2011 at 11:53 AM, Stephen Skory <s at skory.us> wrote:
> >> > Hi Matt,
> >> >
> >> >> I would propose it accept either a string that identifies an existing
> >> >> recipe or a callable.
> >> >
> >> > I don't quite see how this is simpler, unless you're proposing that I
> >> > write a whole bunch of built-in recentering functions in this new
> >> > file. Maybe I'm misunderstanding you? I'm sorry that I'm thick!
> >> >
> >> >
> >> > --
> >> > Stephen Skory
> >> > s at skory.us
> >> > http://stephenskory.com/
> >> > 510.621.3687 (google voice)
> >> > _______________________________________________
> >> > Yt-dev mailing list
> >> > Yt-dev at lists.spacepope.org
> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >> >
> >> _______________________________________________
> >> Yt-dev mailing list
> >> Yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> > _______________________________________________
> > Yt-dev mailing list
> > Yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110414/85e5124d/attachment.htm>