[yt-dev] Coordinate handling pull request

[Casey W. Stark]

Hey Matt.

Sounds good. I would guess the dimensionality issue comes down to
implementation, but I think subclasses are fine.

I am -1 on using abstract classes in general. Completely a style thing, but
I think it ends up making things harder.

- Casey


On Wed, Aug 29, 2012 at 7:52 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> >
> _______________________________________________
> 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/d20d540c/attachment.html>