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
I think this color will look nice on our bikeshed.
On Mon, Feb 27, 2012 at 3:49 PM, Sam Skillman <email@example.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.
> On Mon, Feb 27, 2012 at 1:38 PM, Britton Smith <firstname.lastname@example.org>
>> 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?
>> On Mon, Feb 27, 2012 at 3:18 PM, Stephen Skory <email@example.com> 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
>>> 510.621.3687 (google voice)
>>> yt-dev mailing list
>> yt-dev mailing list
> yt-dev mailing list
yt-dev mailing list