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

[Britton Smith]

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?

Britton


On Wed, Jul 23, 2014 at 9:59 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Britton,
>
> On Tue, Jul 22, 2014 at 5:46 PM, Britton Smith <brittonsmith at gmail.com>
> 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 at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140723/59a6e916/attachment.htm>