My goals for 2.5:<div><br></div><div>Re-written, modularized, amr_kdtree. This will allow for kd-tree decomp of generalized collections of grids as well as future optimization, as well as parallelization over arbitrary N processors, not just power of 2!</div>
<div>Alpha channel integration for the rendering, allowing for easier control of opaque and transparent features in the same image.</div><div><br></div><div>Neither of these necessarily belong in the 3.0 development IMO, but I could be convinced to work in that sandbox. Both of these are working in an alpha state right now.</div>
<div><br></div><div>Sam</div><div><br><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 9:46 AM, 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 all,<br>
<br>
Now that 2.4 is out, I wanted to update you on where this roadmap<br>
(from early June, two months ago today!) is. It slipped a bit, but I<br>
think we're still broadly on track.<br>
<br>
My current plan is to focus on development of the 3.0 branch/fork,<br>
which is located here:<br>
<br>
<a href="http://bitbucket.org/yt_analysis/yt-3.0" target="_blank">http://bitbucket.org/yt_analysis/yt-3.0</a><br>
<br>
It is nearly functional for all major functions from the patch-based<br>
perspective, but I am still working on projections and a handful of<br>
other operations -- flushing data back to grids (for clump finding),<br>
masking of cells (for extracted regions), and a few other medium-level<br>
features. Once it has reached feature completeness for patch-based, I<br>
think it will be ready to have many of you start testing it, kicking<br>
the tires, maybe even moving your development there. I'll update this<br>
group as I make progress, but I'd also be very appreciative if anyone<br>
wants to start testing it with me and working on it. I'm quite<br>
excited about some aspects of it, and I've already been pleased with<br>
simplifications in several areas.<br>
<br>
We should still probably leave open the possibility of a 2.5 release,<br>
but with a much shorter changelog than 2.4 had! :)<br>
<br>
I'll be around in IRC as well as on the mailing list if anyone has any<br>
concerns, suggestions, or wants to get involved in this.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jun 7, 2012 at 4:50 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> Sam and I are working on issuing a PR about the volume rendering<br>
> refactor. This is the last major code change to go in place for 2.4,<br>
> pending the quad_proj changes being accepted or rejected. I'm still<br>
> thinking about this refine_by issue, and that might also make it in.<br>
> After the volume_refactor, it's just testing and documentation left:<br>
><br>
> <a href="https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.4" target="_blank">https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.4</a><br>
><br>
> After 2.4 is released, I am going to shift my new development<br>
> exclusively to the yt-3.0 branch, which is currently hosted here:<br>
><br>
> <a href="http://bitbucket.org/yt_analysis/yt-3.0" target="_blank">http://bitbucket.org/yt_analysis/yt-3.0</a><br>
><br>
> This will include geometry refactoring and many remaining<br>
> de-Enzoifications of the code base. 3.0 is nearing a usable state,<br>
> but will not be ready for production for a while. However, I think<br>
> that allowing the codebases to diverge too rapidly will lead to<br>
> problems: a fracturing. So once the 3.0 codebase can muster feature<br>
> parity with 2.x, I am going to ask that all development on the 2.x<br>
> branch cease, and all pull requests for features and new functionality<br>
> be applied only to the 3.0 branch. In advance of this, I would like<br>
> to solicit help: we've identified a number of relatively<br>
> straightforward changes to this code base that can and should be made.<br>
> For instance, the changing of field names. I'd also like to consider<br>
> moving to a more spread-out source code layout, like one class per<br>
> file. Changes like these make it difficult to do cross-branch merges<br>
> and transplants, which is why I would like to save them for after<br>
> feature parity has been reached and development on 2.x has halted.<br>
><br>
> Previous threads:<br>
><br>
> <a href="http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001852.html" target="_blank">http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001852.html</a><br>
> <a href="http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001868.html" target="_blank">http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001868.html</a><br>
> <a href="http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001830.html" target="_blank">http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001830.html</a><br>
> <a href="http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001941.html" target="_blank">http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001941.html</a><br>
> <a href="http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001949.html" target="_blank">http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001949.html</a><br>
><br>
> If anyone has any strong objections to this strategy, please reply.<br>
><br>
> Estimated Timeline:<br>
><br>
> * June 26, 2.4 release<br>
> * July 30, 3.0 reaches rough feature parity<br>
> * Fall sometime: 3.0 merged into main 'yt' branch<br>
> * Some time after that: 3.0 released<br>
><br>
> Criteria for Feature Parity:<br>
><br>
> * All patch-based AMR codes support data region selection<br>
> * Parallelism is functional for all parallel-capable routines<br>
> * All patch-based AMR codes support projections, slices, cutting planes<br>
> * All patch-based AMR codes support volume rendering<br>
> * All patch-based AMR codes support halo finding<br>
> * Octree-based AMR codes (RAMSES and ART) support data region selection<br>
> * Octree-based AMR codes (RAMSES and ART) support slices, projections<br>
> and cutting planes<br>
><br>
> If any of you are interested in helping with this reengineering<br>
> effort, I would be extremely interested in collaborating. My goal for<br>
> this effort is to focus on making yt a future-compatible code, and<br>
> changing it from an organically grown system into one that we design<br>
> based on the years of experience we all have now had with it.<br>
><br>
> -Matt<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>