[Yt-dev] yt structure

[Matthew Turk]

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 at 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 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
>
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>