Hi all,
With the new halo analysis machinery that Britton, Brian C and Hilary have been working on getting integrated into mainline, do we still need the old halo objects machinery?
It seems to me that if we are able to replicate all the functionality, *and* call the old halo finders, we don't need the actual code for "class Halo" and "class HaloFinder" and the like. This is the stuff that's mostly in halo_objects.py in yt/analysis_modules/halo_finding/ .
Britton, Brian and Hilary -- does that sound okay to you?
-Matt
I know you're not asking me, but as a user of the old halo objects, I'm OK with this moving forward. The only suggestion I have is a short document in the yt 3.0 docs explaining the switch and roughly how to replicate basic functionality. I think some of that already exists, though.
Cameron
On Sun, Mar 23, 2014 at 2:46 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi all,
With the new halo analysis machinery that Britton, Brian C and Hilary have been working on getting integrated into mainline, do we still need the old halo objects machinery?
It seems to me that if we are able to replicate all the functionality, *and* call the old halo finders, we don't need the actual code for "class Halo" and "class HaloFinder" and the like. This is the stuff that's mostly in halo_objects.py in yt/analysis_modules/halo_finding/ .
Britton, Brian and Hilary -- does that sound okay to you?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
First off, Cameron, I'm glad you're on board with this. As someone who used that functionality, it's important that you're not left high and dry.
The original Halo object had a pretty limited scope and was basically only usable inside the halo finding operations. I would definitely like to see us move to the new Halo object in yt/analysis_modules/halo_analysis/halo_object.py since it's the one being used with the HaloCatalog. I think we can also get rid of the HaloFinder class since we are replicating all of its functionality as well. I think, in general, we should be migrating all halo related functionality into yt/analysis_modules/halo_analysis.
Britton
On Mon, Mar 24, 2014 at 4:30 AM, Cameron Hummels chummels@gmail.com wrote:
I know you're not asking me, but as a user of the old halo objects, I'm OK with this moving forward. The only suggestion I have is a short document in the yt 3.0 docs explaining the switch and roughly how to replicate basic functionality. I think some of that already exists, though.
Cameron
On Sun, Mar 23, 2014 at 2:46 PM, Matthew Turk matthewturk@gmail.comwrote:
Hi all,
With the new halo analysis machinery that Britton, Brian C and Hilary have been working on getting integrated into mainline, do we still need the old halo objects machinery?
It seems to me that if we are able to replicate all the functionality, *and* call the old halo finders, we don't need the actual code for "class Halo" and "class HaloFinder" and the like. This is the stuff that's mostly in halo_objects.py in yt/analysis_modules/halo_finding/ .
Britton, Brian and Hilary -- does that sound okay to you?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I would agree with removing the old stuff. After seeing how flexible and powerful Britton’s improvements are, I don’t really see a compelling reason to keep it.
-Brian
On Mar 24, 2014, at 3:03 AM, Britton Smith brittonsmith@gmail.com wrote:
First off, Cameron, I'm glad you're on board with this. As someone who used that functionality, it's important that you're not left high and dry.
The original Halo object had a pretty limited scope and was basically only usable inside the halo finding operations. I would definitely like to see us move to the new Halo object in yt/analysis_modules/halo_analysis/halo_object.py since it's the one being used with the HaloCatalog. I think we can also get rid of the HaloFinder class since we are replicating all of its functionality as well. I think, in general, we should be migrating all halo related functionality into yt/analysis_modules/halo_analysis.
Britton
On Mon, Mar 24, 2014 at 4:30 AM, Cameron Hummels chummels@gmail.com wrote: I know you're not asking me, but as a user of the old halo objects, I'm OK with this moving forward. The only suggestion I have is a short document in the yt 3.0 docs explaining the switch and roughly how to replicate basic functionality. I think some of that already exists, though.
Cameron
On Sun, Mar 23, 2014 at 2:46 PM, Matthew Turk matthewturk@gmail.com wrote: Hi all,
With the new halo analysis machinery that Britton, Brian C and Hilary have been working on getting integrated into mainline, do we still need the old halo objects machinery?
It seems to me that if we are able to replicate all the functionality, *and* call the old halo finders, we don't need the actual code for "class Halo" and "class HaloFinder" and the like. This is the stuff that's mostly in halo_objects.py in yt/analysis_modules/halo_finding/ .
Britton, Brian and Hilary -- does that sound okay to you?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.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
-
Brian Crosby -
Britton Smith -
Cameron Hummels -
Matthew Turk