RFC: (yt-3.0) Accessing fluids and particles
Hi all, During the geometry handling hangout today (which I think was quite successful!) the question came up of how to handle accessing particles and fluids came up. The suggestion has been put forth to change all access of field values into .fluid/.field and .particles, with the optional type specifier as the first attribute. This would look like: dd = pf.h.all_data() dd.fluid["Dust"]["Density"] or dd = pf.h.all_data() dd.particles["dark_matter"]["velocity-x"] I have an opinion on what we should do, but I'd like to hear from others before continuing down this path. Here are the options: 1) Keep everything as is for now, requiring users to manually selection things like particle type and fluid type (in case of multiple fluids) and just say who cares if people have multiple particle types. 2) Move to requiring dict-of-dicts for particles only, and allow fluids to exist as is. i.e., dd["Density"] dd.particles["dark_matter"]["velocity-x"] 3) Move to requiring both .fluids and .particles, and make both dict-of-dicts. dd.fluid[:]["Density"] # for all densities summed dd.particles[:]["velocity-x"] 4) Leave things mostly as is, but use tuple-access for types. This would mean: dd["Density"] # gives the total density dd["dust","Density"] # only dust density dd["particle-velocity-x"] dd["PopII", "particle-velocity-x"] 5) Use the object for fluids with optional type specifier, and dict-of-dicts for particles: dd["Density"] dd["dust","Density"] dd.particles["dark_matter"]["velocity-x"] -- Votes? To be honest, thinking about this worries me a bit. I'm inclined not to break old code unless absolutely necessary. But, I would like to support two-fluids in a more reasonable way, and I also want to support multiple particle types (a more common use case, I think) more elegantly. As a rule, even though this is coming down the road a bit, I'd like to try to keep in mind that big changes are frustrating for people, so for each change that is made a good reason for making it should be present. In this case, I initially wanted to make it much easier to select individual particle types, but then the discussion grew from there. We need to consider both aesthetic and technical challenges. I'd like to hear any suggestions or feedback on these items, or alternate suggestions. Thanks, Matt
Hi everyone, I'm not sure I have a strong opinion one way or the other, except to say that .fluid bothers me in the event of multiple fluid fields. We may have native fluid fields and 'interpolated' fluid fields based on SPH particles. We might even have particle types with different force resolutions (dark matter may be coarser than star or gas particles, for example), and therefore may want different smoothing kernels, and different fluids for each kernel. I'd like break away from the idea of one canonical 'fluid' quantity... If we did choose a dd.fluid approach, couldn't we just alias calls like dd["Density"] to go dd.fluid, and deprecate it over time? chris On Mon, Feb 27, 2012 at 11:20 AM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
During the geometry handling hangout today (which I think was quite successful!) the question came up of how to handle accessing particles and fluids came up.
The suggestion has been put forth to change all access of field values into .fluid/.field and .particles, with the optional type specifier as the first attribute. This would look like:
dd = pf.h.all_data() dd.fluid["Dust"]["Density"]
or
dd = pf.h.all_data() dd.particles["dark_matter"]["velocity-x"]
I have an opinion on what we should do, but I'd like to hear from others before continuing down this path. Here are the options:
1) Keep everything as is for now, requiring users to manually selection things like particle type and fluid type (in case of multiple fluids) and just say who cares if people have multiple particle types. 2) Move to requiring dict-of-dicts for particles only, and allow fluids to exist as is. i.e.,
dd["Density"] dd.particles["dark_matter"]["velocity-x"]
3) Move to requiring both .fluids and .particles, and make both dict-of-dicts.
dd.fluid[:]["Density"] # for all densities summed dd.particles[:]["velocity-x"]
4) Leave things mostly as is, but use tuple-access for types. This would mean:
dd["Density"] # gives the total density dd["dust","Density"] # only dust density dd["particle-velocity-x"] dd["PopII", "particle-velocity-x"]
5) Use the object for fluids with optional type specifier, and dict-of-dicts for particles:
dd["Density"] dd["dust","Density"] dd.particles["dark_matter"]["velocity-x"] --
Votes?
To be honest, thinking about this worries me a bit. I'm inclined not to break old code unless absolutely necessary. But, I would like to support two-fluids in a more reasonable way, and I also want to support multiple particle types (a more common use case, I think) more elegantly. As a rule, even though this is coming down the road a bit, I'd like to try to keep in mind that big changes are frustrating for people, so for each change that is made a good reason for making it should be present. In this case, I initially wanted to make it much easier to select individual particle types, but then the discussion grew from there. We need to consider both aesthetic and technical challenges.
I'd like to hear any suggestions or feedback on these items, or alternate suggestions.
Thanks,
Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton, On Mon, Feb 27, 2012 at 3:38 PM, Britton Smith <brittonsmith@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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 On Feb 27, 2012 3:43 PM, "Matthew Turk" <matthewturk@gmail.com> wrote:
Hi Britton,
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
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
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
On Mon, Feb 27, 2012 at 3:38 PM, Britton Smith <brittonsmith@gmail.com> wrote: trade-off the 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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I think the guess 'n' fail approach is the best one. +1 -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
+1 Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum On Feb 27, 2012, at 12:38 PM, Britton Smith 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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4f4be9cf7682001714235! _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4f4be9cf7682001714235!
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@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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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@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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 On Mon, Feb 27, 2012 at 1:21 PM, Matthew Turk <matthewturk@gmail.com> wrote:
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
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@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
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
On Mon, Feb 27, 2012 at 3:49 PM, Sam Skillman <samskillman@gmail.com> wrote: trade-off 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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (8)
-
Britton Smith -
Casey W. Stark -
Christopher Moody -
j s oishi -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman -
Stephen Skory