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