<div dir="ltr">Deal. I'll move the rest and leave that one for you.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 10:36 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jul 23, 2014 at 4:30 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Hi Matt,<br>
><br>
> The source will always exist in the history as well. My personal preference<br>
> is for yt-3.0 to be clean of broken modules when it is released to avoid<br>
> confusion. Is it alright to leave it be in yt-2.x and get rid of it in 3.0<br>
> for now?<br>
<br>
</div>Well, so Mike, Sam and I were going to use it as a starting point for<br>
some immediate work, which would necessitate bringing it up to date.<br>
How about this -- if I move it into the halo_analysis directory and<br>
update it, can it stay?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Britton<br>
><br>
><br>
><br>
> On Wed, Jul 23, 2014 at 9:59 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> Hi Britton,<br>
>><br>
>> On Tue, Jul 22, 2014 at 5:46 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>> wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > I want to address the state of halo merger trees in yt-3.0. As it<br>
>> > stands,<br>
>> > one cannot use yt-3.0 to create a merger tree. The two existing methods<br>
>> > have not been ported over from yt-2.x and now rely on functionality that<br>
>> > has<br>
>> > seen significant changes. For example, the old HaloProfiler has been<br>
>> > removed, and the outputs of all yt halo finders have been redesigned to<br>
>> > work<br>
>> > with the new halo_analysis framework discussed in YTEP-0012. Both of<br>
>> > these<br>
>> > changes break one or both of the current merger trees. Thus, it will<br>
>> > take<br>
>> > significant work to make them functional within yt-3.0. In addition,<br>
>> > the<br>
>> > aim has been to design a new merger tree that would work with the<br>
>> > halo_analysis framework (discussed as HaloCatalogTimeSeries in the<br>
>> > YTEP).<br>
>> ><br>
>> > In summary, unless there is someone willing to champion them, I believe<br>
>> > the<br>
>> > merger trees in yt-2.x have come to the end of their roads. I could be<br>
>> > convinced otherwise, but given the fact that they are broken at this<br>
>> > time,<br>
>> > we need to make a decision by the release of yt-3.0. I see a few<br>
>> > options:<br>
>> ><br>
>> > 1. Remove the existing merger trees from the yt-3.0 codebase now, but<br>
>> > leave<br>
>> > the page in the documentation containing only a note that this<br>
>> > functionality<br>
>> > does not yet exist in 3.0, but is still available in 2.x. I think there<br>
>> > are<br>
>> > a few people (including me) who have building a new 3.0-compliant merger<br>
>> > tree on their radar so I do not envision us going without for too long.<br>
>><br>
>> I'd like to request that we keep the enzofof_merger_tree.py code. I<br>
>> want to use that as a starting point for future development. Other<br>
>> than that, I am in favor of this option.<br>
>><br>
>> -Matt<br>
>><br>
>> ><br>
>> > 2. Keep the existing code and throw NotImplementedYet exceptions when it<br>
>> > is<br>
>> > imported. Additionally, remove all imports to non-existing machinery<br>
>> > like<br>
>> > the HaloProfiler. Add a note to the documentation stating that this no<br>
>> > longer works but is waiting for help to be ported.<br>
>> ><br>
>> > 3. Fix one or both of them now to at least be functional (if not<br>
>> > optimally)<br>
>> > by the yt-3.0 release. I personally cannot do this. If you vote for<br>
>> > this<br>
>> > option, you should be willing to commit to do this.<br>
>> ><br>
>> > I am mostly interested in hearing from people who have a stake in the<br>
>> > halo<br>
>> > merger trees, but all input is welcome.<br>
>> ><br>
>> > Britton<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> ><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>