Hey Matt.

I think this would be a big improvement, but I was wondering how it interacts with other yt pieces. Does each output have geometry and coordinate_handler objects as attributes?

Is it possible to replace axis_name, axis_id, x_axis, and y_axis with only axis_names = ['x', ...]?

- Casey


On Wed, Aug 29, 2012 at 7:28 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,

I've issued a pull request to the 3.0 repository, as I think it
warrants discussion.  It's here:

https://bitbucket.org/yt_analysis/yt-3.0/pull-request/5/initial-import-of-coordinate-handler-class

This includes a first pass at a coordinate handling system.  This is
distinct from a geometry handling system; the coordinates here refer
to how we handle coordinates and spatial locations internally, whereas
geometry refers to how data is distributed throughout a domain and
throughout places on disk.  For instance, coordinate handling would be
cartesian, polar, spherical.

The reason I'm bringing it up for discussion is that I believe we want
to move as much coordinate handling and transformation into a
separate, well-defined class as possible.  Periodicity, distances and
so on are all currently scattered throughout the code, and I'd like to
try to consolidate them.  Additionally, as new coordinate systems
(polar, spherical) are added, we'll need clear ways to delegate
responsibility for things like "How do I calculate path length as I
integrate?" or "What's the way to turn this into an image?"  I believe
the best way to do that is to attach a coordinate system to the
dataset object itself.  (We now have a polar pixelizer
http://i.imgur.com/a4UGg.png !)

The interface is currently set such that you need to define these
methods and properties in order to implement a coordinate system:

coordinate_fields (this may go away, but it's for the analogs of 'x',
'y', 'z', as well as volume)
pixelize
convert_from_cartesian
convert_to_cartesian
axis_name
axis_id
x_axis
y_axis
period

Some of these currently live in dictionaries in
yt/utilities/definitions.py, which is pretty sub-optimal.  I'd like to
ask for feedback:

1) Do these methods sufficiently cover everything we need to know in
yt about a coordinate system?  Should any be added?
2) Do we need to directly address dimensionality as a separate subclass?
3) Should any of these be removed?

This will also help address these issues:

https://bitbucket.org/yt_analysis/yt/issue/418/use-a-right-handed-coordinate-system
https://bitbucket.org/yt_analysis/yt/issue/422/ray-casting-in-cylindrical-coordinates
https://bitbucket.org/yt_analysis/yt/issue/421/refactor-non-cartesian-geometry
https://bitbucket.org/yt_analysis/yt/issue/345/non-cartesian-geometry
https://bitbucket.org/yt_analysis/yt/issue/205/periodicity

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