[Yt-dev] yt structure

[Britton Smith]

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 at 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 at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20091209/a803f974/attachment.htm>