Re: [yt-dev] halo merger tree in yt-3.0

On Wed, Jul 23, 2014 at 4:30 PM, Britton Smith wrote:

Hi Matt,

The source will always exist in the history as well. My personal preference is for yt-3.0 to be clean of broken modules when it is released to avoid confusion. Is it alright to leave it be in yt-2.x and get rid of it in 3.0 for now?

Well, so Mike, Sam and I were going to use it as a starting point for some immediate work, which would necessitate bringing it up to date. How about this -- if I move it into the halo_analysis directory and update it, can it stay?

Britton

On Wed, Jul 23, 2014 at 9:59 PM, Matthew Turk wrote:

...

Hi Britton,

On Tue, Jul 22, 2014 at 5:46 PM, Britton Smith wrote:

...

Hi all,

I want to address the state of halo merger trees in yt-3.0. As it stands, one cannot use yt-3.0 to create a merger tree. The two existing methods have not been ported over from yt-2.x and now rely on functionality that has seen significant changes. For example, the old HaloProfiler has been removed, and the outputs of all yt halo finders have been redesigned to work with the new halo_analysis framework discussed in YTEP-0012. Both of these changes break one or both of the current merger trees. Thus, it will take significant work to make them functional within yt-3.0. In addition, the aim has been to design a new merger tree that would work with the halo_analysis framework (discussed as HaloCatalogTimeSeries in the YTEP).

In summary, unless there is someone willing to champion them, I believe the merger trees in yt-2.x have come to the end of their roads. I could be convinced otherwise, but given the fact that they are broken at this time, we need to make a decision by the release of yt-3.0. I see a few options:

1. Remove the existing merger trees from the yt-3.0 codebase now, but leave the page in the documentation containing only a note that this functionality does not yet exist in 3.0, but is still available in 2.x. I think there are a few people (including me) who have building a new 3.0-compliant merger tree on their radar so I do not envision us going without for too long.

I'd like to request that we keep the enzofof_merger_tree.py code. I want to use that as a starting point for future development. Other than that, I am in favor of this option.

-Matt

...

2. Keep the existing code and throw NotImplementedYet exceptions when it is imported. Additionally, remove all imports to non-existing machinery like the HaloProfiler. Add a note to the documentation stating that this no longer works but is waiting for help to be ported.

3. Fix one or both of them now to at least be functional (if not optimally) by the yt-3.0 release. I personally cannot do this. If you vote for this option, you should be willing to commit to do this.

I am mostly interested in hearing from people who have a stake in the halo merger trees, but all input is welcome.

Britton

_______________________________________________ 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