Howdy y'all, I'm wondering if there is a system to deciding when something belongs in yt.lagos (like the HaloFinders), or in yt.extensions (like the HaloProfiler)? For example, I'm thinking of adding a simple bit of code that will calculate the star formation history (Msol/year, for example) for a given set of stars. Would that go in extensions or in lagos? The best I can tell is that extensions are more secondary, as in they are a post-processor of already refined data, while lagos handles the raw data and refines it down. Thanks! _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
Hi Stephen,
I'm wondering if there is a system to deciding when something belongs in yt.lagos (like the HaloFinders), or in yt.extensions (like the HaloProfiler)? For example, I'm thinking of adding a simple bit of code that will calculate the star formation history (Msol/year, for example) for a given set of stars. Would that go in extensions or in lagos? The best I can tell is that extensions are more secondary, as in they are a post-processor of already refined data, while lagos handles the raw data and refines it down.
Yeah, the extensions are supposed to be secondary. However, I'd like to deprecate the current directory structure and move to a new layout, where we get rid of 'raven' and 'lagos' and the other snow crash names, instead moving to a better system of describing the contents of directories. It's just been put off for a while. Ideally, what do you think is a good name for a subpackage that covers, broadly, the type of analysis that this code does? The document I wrote up about a year ago -- now somewhat out of date -- that describes what I'd like to do with the reorganization is here: http://docs.google.com/Doc?docid=0AVDaRHnSGW8ZZHJ3cTNkM182NGhibXJtOWZ2&hl=en Maybe something like yt.synthetic_observations or something? yt.physics seems a bit glib. :) -Matt
Matt,
Ideally, what do you think is a good name for a subpackage that covers, broadly, the type of analysis that this code does?
I guess it depends on how fine-grained we wish to be in subpackage names. At the finest level, it would go in a star_analysis package.
Maybe something like yt.synthetic_observations or something? yt.physics seems a bit glib. :)
I'm not sure yt.physics is even appropriate, yt doesn't do physics, strictly. 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. 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. _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
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
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
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
participants (3)
-
Britton Smith -
Matthew Turk -
Stephen Skory