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

[Sam Skillman]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120227/7216e376/attachment.html>