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
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
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
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