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

[Matthew Turk]

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
>