When we start to think about this, we should focus first on what the essentials are for YT and then work outward toward things that are increasingly non-essential.  One thing I'd like to see that we never really got going is a community venue for analysis tools.  This would be things that shouldn't be found in the core source routines, but more like optional add-ins that may or may not come with the main code when you get it.  One example that comes to mind is a place for new derived fields.  I've got some rather complicated ones and I know others do to.  I don't want to mess up EnzoFields or UniversalField, but I would like to have some place for people to get them.<br>
<br>Anyway, I think it's important to distinguish between core functionality, sort of level 1 analysis that almost anyone who runs enzo will want to do (halo finder, halo profiler, maybe clump finder), and then things that truly are extensions of all this.<br>
<br>Britton<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 8:55 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> I'm not sure yt.physics is even appropriate, yt doesn't do physics, strictly<br>
<br>
</div>I don't anticipate that changing in the near future.<br>
<div class="im"><br>
> I think the best way to reorg is by hierarchical function, which is more or less what you've described in the google doc. Under yt. the dirs should be simple, like yt.data_io, yt.analysis, yt.plotting, yt.gui. And under those more refined, yt.analysis.stars, yt.analysis.haloes, yt.analysis.fields. Well, this is just my two cents. I'm just writing my thoughts down, I haven't really contemplated how hard it would be to reorg this way.<br>

<br>
</div>Perhaps that's the best way to go -- yt.analysis subpackage?  Does<br>
anyone else have any ideas?<br>
<div class="im"><br>
> My suggestion is if we are to reorganize the directories, we should do it all at once, meaning it should coincide with a point release of yt, to keep the distributions (svn, hg) more or less comparable. Otherwise we'll just go crazy trying to juggle the two.<br>

<br>
</div>I can't imagine doing it any other way.  One of the reasons I've been<br>
sitting on this document for a year is that there hadn't been a good<br>
time.  I see this coinciding with pushing toward a 2.0 -- which would<br>
need to include first-class time series analysis, the software volume<br>
renderer (possibly a hardware one as well), the VTK stuff, the<br>
Parallel HOP, embedded support described in the docs, the new particle<br>
IO, the reorg, possibly some other stuff that hasn't been done yet.<br>
<br>
Anybody else have any thoughts on reorg?<br>
<br>
-Matt<br>
<div><div></div><div class="h5">_______________________________________________<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>