+1<div><br><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 1:21 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay, let's do this then.<br>
<br>
1) Try to figure out fields accessed on the main object. If there's a<br>
problem, throw an error.<br>
2) If someone wants to access a type of particle or a type of fluid,<br>
mandate that they handle it by calling out dict-of-dict .fluid and<br>
.particle attributes.<br>
<br>
I think this color will look nice on our bikeshed.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Feb 27, 2012 at 3:49 PM, Sam Skillman <<a href="mailto:samskillman@gmail.com">samskillman@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I like Britton's suggestion the most so far. I'd like to look at .particles<br>
> and .fluid as wrappers around the current infrastructures, rather than a<br>
> replacement. (Just saw matt's response come in, which is also in line with<br>
> this). That way we can provide a method for the user to specify (Jeez, busy<br>
> list, just got Nathan's response!) multiple fluids. This would allow for<br>
> something like obj.fluid['default']['DivV'] and obj.fluid['dust']['DivV']<br>
> and it would know which velocities to pick up for each. I think I better<br>
> send my response now, as I just got Jeff's +1!. Anyways, I think this is<br>
> looking good. We can mandate the frontend specifying a "default" or have a<br>
> method of fallbacks.<br>
><br>
> I'll jump on the +1 bandwagon.<br>
><br>
> Sam<br>
><br>
> On Mon, Feb 27, 2012 at 1:38 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I think there is a lot of value to not having yt 3.0 be jarring to users<br>
>> when they are introduced to it. I think we are wrestling with a trade-off<br>
>> between drawing technical distinctions and not making for a difficult<br>
>> transition for the user, as well as those that work on this.<br>
>><br>
>> So far, yt does a pretty good job figuring out on its own the nature of<br>
>> the field that's being requested. I propose that we have both<br>
>> obj.fluid['whatever'] and obj.particles['whatever'] as means of explicitly<br>
>> stating the type of field being requested, but that we also allow for<br>
>> obj['whatever'] and let yt try to figure it out first. If yt can't figure<br>
>> out what type of field it's being asked to get, it can throw an exception<br>
>> and ask for specific direction.<br>
>><br>
>> Would this satisfy people?<br>
>><br>
>> Britton<br>
>><br>
>><br>
>> On Mon, Feb 27, 2012 at 3:18 PM, Stephen Skory <<a href="mailto:s@skory.us">s@skory.us</a>> wrote:<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> I've been thinking about things, and this actually dovetails onto<br>
>>> Chris' comments as well, I think. The way I see it, in order to get to<br>
>>> data from a dataset, here are the abstract levels yt goes through:<br>
>>><br>
>>> 1. Dataset Identifier (pf)<br>
>>> 2. Data Container (pf.obj)<br>
>>> 3. Data Type (particles, fluid)<br>
>>> 4. Data Type Class (POPIII, interpolated fluid)<br>
>>> 5. Data Type Specific Data ("x", "particle_position_x")<br>
>>><br>
>>> What we're struggling with is where to put level #3 in our syntax. As<br>
>>> we currently have it, it's done at the finest level with the<br>
>>> generalized dict access for a specific thing (dd["x"],<br>
>>> dd["ParticleMass"], dd["DerivedField"]), and yt works out the rest. I<br>
>>> don't know if I myself like this idea, but we might want to consider<br>
>>> putting the Data Type specification up higher. For example we could<br>
>>> have Data Type-specific data containers (dd_fluid =<br>
>>> pf.h.all_data("fluid")). Or, I like this even less, but it's<br>
>>> conceivable that there could be a Data Type-specific load (pf_parts =<br>
>>> load("DD1234", "particles").<br>
>>><br>
>>> I'm not making any suggestions here, I just want to see if anyone sees<br>
>>> any benefit from changing the level at which Data Type is specified?<br>
>>> Feel free to say "no, stupidest idea since lawn darts." I'm not<br>
>>> convinced it isn't.<br>
>>><br>
>>> --<br>
>>> Stephen Skory<br>
>>> <a href="mailto:s@skory.us">s@skory.us</a><br>
>>> <a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
>>> <a href="tel:510.621.3687" value="+15106213687">510.621.3687</a> (google voice)<br>
>>> _______________________________________________<br>
>>> yt-dev mailing list<br>
>>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>