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

Matthew Turk matthewturk at gmail.com
Mon Feb 27 12:43:33 PST 2012


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
>



More information about the yt-dev mailing list