[yt-dev] Coordinate handling pull request

[Matthew Turk]

On Wed, Aug 29, 2012 at 10:43 AM, Casey W. Stark <caseywstark at gmail.com> wrote:
> 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?

Yup, that is the plan.  The idea is that we move all of the IO and
particle/fluid selection into the geometry handler, and the handling
of spatial layout to the coordinate handler.  This would mean, for
instance, that we could push periodicity as well as path length into
the coordinate handler; this would remove some of the need to
constantly do wraparound checks and the like.

There is still somewhat the issue that *selection* of points to
understand coordinate systems, which will require a bit more thought
in the future but I think is still a tractable problem.

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

It is, but not with abc.abstractproperty.  (Initially I figured the
cost of creating the dicts was low enough that we could do this to
avoid worrying about mutable, class-level properties, but I think
perhaps I like yours better.)  I'll remove some of the fancier
ABC-stuff and slim it down.

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