[yt-dev] Coordinate handling pull request

[Casey W. Stark]

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 at 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 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/20120829/a482d422/attachment.html>