Hi guys, I've started experimenting with the yt reorganization. This week a couple of us will be in Austin, in person, so I anticipate making some motion then. When I started fiddling, I didn't have access to email, so I didn't have Stephen's suggested package organization -- which, in retrospect, makes a lot of sense. I think I'm going to focus on: yt amr_utils analysis data_io base enzo orion gadget, chombo, etc data_objects plotting parallel_tools file_handling extensions the only issue, conceptually, that I am having is with the classification of things like code-specific fields under data_io/[code]/fields.py . Not sure about that. Anybody have any thoughts? Anyway, just a short update is all. The work will be in a named branch, kept in a separate repo, called "reorganization" and "yt-reorg" respectively. Merging this into SVN will be tricky, but do-able, but on a medium-timescale, once it's stable. We'll do a point-release before any changes. -Matt On Thu, Dec 10, 2009 at 5:15 AM, Britton Smith <brittonsmith@gmail.com> wrote:
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
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org