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@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@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@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@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@skory.us
>> > http://stephenskory.com/
>> > 510.621.3687 (google voice)
>> > _______________________________________________
>> > Yt-dev mailing list
>> > Yt-dev@lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
_______________________________________________
Yt-dev mailing list
Yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org