[yt-dev] RFC: (yt-3.0) Accessing fluids and particles

[j s oishi]

+1
On Feb 27, 2012 3:43 PM, "Matthew Turk" <matthewturk at gmail.com> wrote:

> Hi Britton,
>
> On Mon, Feb 27, 2012 at 3:38 PM, Britton Smith <brittonsmith at gmail.com>
> wrote:
> > I think there is a lot of value to not having yt 3.0 be jarring to users
> > when they are introduced to it.  I think we are wrestling with a
> trade-off
> > between drawing technical distinctions and not making for a difficult
> > transition for the user, as well as those that work on this.
> >
> > So far, yt does a pretty good job figuring out on its own the nature of
> the
> > field that's being requested.  I propose that we have both
> > obj.fluid['whatever'] and obj.particles['whatever'] as means of
> explicitly
> > stating the type of field being requested, but that we also allow for
> > obj['whatever'] and let yt try to figure it out first.  If yt can't
> figure
> > out what type of field it's being asked to get, it can throw an exception
> > and ask for specific direction.
> >
> > Would this satisfy people?
>
> Yes, this sounds like the best bet.  I think:
>
> obj["particle_field"]
> obj["fluid_field"]
> obj.fluid[type][field]
> obj.particles[type][field]
>
> is my preferred method.  This means that script authors can choose to
> subselect or not, but we're not doing anything too jarring and we're
> not doing anything too unclear, either.  I think this might meet the
> best use case, of wanting *everything* if you query the object, but
> providing the level-3 selection Stephen suggested at just about the
> right place.
>
> -Matt
>
> >
> > Britton
> >
> >
> > On Mon, Feb 27, 2012 at 3:18 PM, Stephen Skory <s at skory.us> wrote:
> >>
> >> Hi all,
> >>
> >> I've been thinking about things, and this actually dovetails onto
> >> Chris' comments as well, I think. The way I see it, in order to get to
> >> data from a dataset, here are the abstract levels yt goes through:
> >>
> >> 1. Dataset Identifier (pf)
> >> 2. Data Container (pf.obj)
> >> 3. Data Type (particles, fluid)
> >> 4. Data Type Class (POPIII, interpolated fluid)
> >> 5. Data Type Specific Data ("x", "particle_position_x")
> >>
> >> What we're struggling with is where to put level #3 in our syntax. As
> >> we currently have it, it's done at the finest level with the
> >> generalized dict access for a specific thing (dd["x"],
> >> dd["ParticleMass"], dd["DerivedField"]), and yt works out the rest. I
> >> don't know if I myself like this idea, but we might want to consider
> >> putting the Data Type specification up higher. For example we could
> >> have Data Type-specific data containers (dd_fluid =
> >> pf.h.all_data("fluid")). Or, I like this even less, but it's
> >> conceivable that there could be a Data Type-specific load (pf_parts =
> >> load("DD1234", "particles").
> >>
> >> I'm not making any suggestions here, I just want to see if anyone sees
> >> any benefit from changing the level at which Data Type is specified?
> >> Feel free to say "no, stupidest idea since lawn darts." I'm not
> >> convinced it isn't.
> >>
> >> --
> >> Stephen Skory
> >> s at skory.us
> >> http://stephenskory.com/
> >> 510.621.3687 (google voice)
> >> _______________________________________________
> >> 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/20120227/da3c4839/attachment.html>