<div dir="ltr">Hi Matt,<div><br></div><div>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?</div>
<div><br></div><div>Britton<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 9:59 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">Hi Britton,<br>
<div><br>
On Tue, Jul 22, 2014 at 5:46 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>> wrote:<br>
</div><div>> Hi all,<br>
><br>
> I want to address the state of halo merger trees in yt-3.0. As it 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 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 work<br>
> with the new halo_analysis framework discussed in YTEP-0012. Both of these<br>
> changes break one or both of the current merger trees. Thus, it will take<br>
> significant work to make them functional within yt-3.0. In addition, 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 YTEP).<br>
><br>
> In summary, unless there is someone willing to champion them, I believe 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 time,<br>
> we need to make a decision by the release of yt-3.0. I see a few options:<br>
><br>
> 1. Remove the existing merger trees from the yt-3.0 codebase now, but leave<br>
> the page in the documentation containing only a note that this functionality<br>
> does not yet exist in 3.0, but is still available in 2.x. I think there 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>
</div>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>
<div><br>
><br>
> 2. Keep the existing code and throw NotImplementedYet exceptions when it is<br>
> imported. Additionally, remove all imports to non-existing machinery 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 optimally)<br>
> by the yt-3.0 release. I personally cannot do this. If you vote for 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 halo<br>
> merger trees, but all input is welcome.<br>
><br>
> Britton<br>
><br>
><br>
</div><div><div>> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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" target="_blank">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></div></div>