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

[Casey W. Stark]

+1


On Mon, Feb 27, 2012 at 1:21 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Okay, let's do this then.
>
> 1) Try to figure out fields accessed on the main object.  If there's a
> problem, throw an error.
> 2) If someone wants to access a type of particle or a type of fluid,
> mandate that they handle it by calling out dict-of-dict .fluid and
> .particle attributes.
>
> I think this color will look nice on our bikeshed.
>
> -Matt
>
> On Mon, Feb 27, 2012 at 3:49 PM, Sam Skillman <samskillman at gmail.com>
> wrote:
> > Hi all,
> >
> > I like Britton's suggestion the most so far.  I'd like to look at
> .particles
> > and .fluid as wrappers around the current infrastructures, rather than a
> > replacement.  (Just saw matt's response come in, which is also in line
> with
> > this).  That way we can provide a method for the user to specify (Jeez,
> busy
> > list, just got Nathan's response!) multiple fluids.  This would allow for
> > something like obj.fluid['default']['DivV'] and obj.fluid['dust']['DivV']
> > and it would know which velocities to pick up for each.  I think I better
> > send my response now, as I just got Jeff's +1!.  Anyways, I think this is
> > looking good.  We can mandate the frontend specifying a "default" or
> have a
> > method of fallbacks.
> >
> > I'll jump on the +1 bandwagon.
> >
> > Sam
> >
> > On Mon, Feb 27, 2012 at 1: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?
> >>
> >> 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
> >
> _______________________________________________
> 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/b212fc84/attachment.htm>