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.

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.

Britton

On Wed, Dec 9, 2009 at 8:55 PM, Matthew Turk <matthewturk@gmail.com> wrote:
> I'm not sure yt.physics is even appropriate, yt doesn't do physics, strictly

I don't anticipate that changing in the near future.

> 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.

Perhaps that's the best way to go -- yt.analysis subpackage?  Does
anyone else have any ideas?

> 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.

I can't imagine doing it any other way.  One of the reasons I've been
sitting on this document for a year is that there hadn't been a good
time.  I see this coinciding with pushing toward a 2.0 -- which would
need to include first-class time series analysis, the software volume
renderer (possibly a hardware one as well), the VTK stuff, the
Parallel HOP, embedded support described in the docs, the new particle
IO, the reorg, possibly some other stuff that hasn't been done yet.

Anybody else have any thoughts on reorg?

-Matt
_______________________________________________
Yt-dev mailing list
Yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org