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.
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.
On Fri, Apr 8, 2011 at 11:53 AM, Stephen Skory <email@example.com> 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
> 510.621.3687 (google voice)
> Yt-dev mailing list
Yt-dev mailing list