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

Matthew Turk matthewturk at gmail.com
Wed Jul 23 14:36:06 PDT 2014


On Wed, Jul 23, 2014 at 4:30 PM, Britton Smith <brittonsmith at gmail.com> 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 <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
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list