<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Note, this will almost certainly fail since the number of star particles won't equal the<br>
number of dark matter particles.</blockquote><div><br></div><div>Whoops! Good catch. I hope the example is useful to get a sense for this otherwise. You could do something like in_units("Msun") instead.</div><div>
<br></div><div>- Casey</div><div><br></div><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 9:59 AM, Douglas Harvey Rudd <span dir="ltr"><<a href="mailto:drudd@uchicago.edu" target="_blank">drudd@uchicago.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><div class="im">
<blockquote type="cite">
<div><br>
</div>
<div>star_particle_masses = dd[("stars", "mass")]</div>
<div>dm_particle_masses = dd[("dark_matter", "mass")]</div>
<div>assert (star_particle_masses < dm_particle_masses).all()</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
</div><div>Note, this will almost certainly fail since the number of star particles won't equal the</div>
<div>number of dark matter particles.</div><div class="im">
<div><br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>Being consistent here, I also say we rename "CellMass" to "mass". This means you would need dd[("gas", "mass")] and dd["mass"] would fail because it is ambiguous. I would prefer really simple field names, but more explicit field "type" selectors. Maybe
that's just me.</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
</div><div>I'm +1 on this as well. I'd rather the code not guess (or be very clear when it is allowing an unspecified type), however this will completely break backwards compatibility in many cases. How much do people care about that for 3.0?</div>
<div><br>
</div>
<div>Doug</div><div><div class="h5">
<div><br>
</div>
<blockquote type="cite">
<div><br>
<div class="gmail_quote">On Thu, Mar 14, 2013 at 6:49 AM, Matthew Turk <span dir="ltr">
<<a href="mailto:matthewturk@gmail.com" target="_blank">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">
Hi Doug,<br>
<div><br>
On Thu, Mar 14, 2013 at 9:31 AM, Douglas Harvey Rudd <<a href="mailto:drudd@uchicago.edu" target="_blank">drudd@uchicago.edu</a>> wrote:<br>
> Great!<br>
><br>
> If you'd like some sample code, clone my branch drudd/yt-3.0-artio and use<br>
> the artio reader on particles.<br>
<br>
</div>
Perfect, I definitely will.<br>
<div><br>
><br>
> In that fork I've also experimented with setting up derived fields with an<br>
> explicit type, say ParticleMassMsun for each of all, stars, and nobody, but<br>
> this seems to break naked requests for data["ParticleMassMsun"], which<br>
> translates the type into 'unknown'.<br>
<br>
</div>
Grr. Okay, I think this is one of my issues. The problem I was<br>
running into was keeping a fast but definite cache of the previously<br>
requested particle type. I'll dig in on this.<br>
<div><br>
><br>
> The star formation spectrum code currently works with untyped fields<br>
> dd["creation_time"]. I'd in principle like to change those to<br>
> ("star","creation_time") to be explicit and future compatible (avoid<br>
> including black holes that also have creation times associated), but that<br>
> will currently break frontends that don't have types or know how to<br>
> subselect by type.<br>
<br>
</div>
I agree 100%. This is an opportunity to also get rid of all of the<br>
"creation_time < 0" lines sprinkled throughout the code. By sticking<br>
all of the particle selection code into the frontends, this is much<br>
more tractable.<br>
<div><br>
><br>
> Another option that would work for artio is have naked requests resolve to<br>
> the correct particle type, if only one particle type supports it, or "all"<br>
> otherwise.<br>
<br>
</div>
I think this is good for the most part, but I am worried it may<br>
interfere with calls by particle type specific fields that are neutral<br>
to the particle type. For instance, imagine a case where you have a<br>
derived field that calls on particle velocity. If that top level<br>
field is called only on stars, then we want to make sure that the call<br>
to velocity resolves only to stars. I think this is tractable, I just<br>
want to make sure that we are careful to ensure that still works.<br>
<br>
FWIW, there is a default_fluid_type attribute. Perhaps identifying<br>
where it is used and then mimicking it for particles would work.<br>
<div>
<div><br>
-Matt<br>
<br>
><br>
><br>
> Douglas Rudd<br>
> Scientific Computing Consultant<br>
> Research Computing Center and<br>
> Kavli Center for Cosmological Physics<br>
> <a href="mailto:drudd@uchicago.edu" target="_blank">drudd@uchicago.edu</a><br>
><br>
> On Mar 14, 2013, at 7:08 AM, "Matthew Turk" <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br>
><br>
> Hi Doug,<br>
><br>
> On Wed, Mar 13, 2013 at 7:56 PM, Douglas Harvey Rudd <<a href="mailto:drudd@uchicago.edu" target="_blank">drudd@uchicago.edu</a>><br>
> wrote:<br>
><br>
> Okay, I had noticed this thread but hadn't fully digested that I had hit the<br>
> very same issue.<br>
><br>
><br>
> I'm +1 on Chris' change, for the exact same reason (ParticleMassMsun for<br>
> star particle types).<br>
><br>
><br>
> Awesome.<br>
><br>
><br>
> Matt: I didn't quite follow your message. I would assume most derived<br>
> fields should be neutral<br>
><br>
> to the type of particle, since they're typically unit conversions. Having<br>
> two particle types with the<br>
><br>
> same field name that are not compatible should be forbidden, otherwise<br>
> ("all", ) would be nonsensical.<br>
><br>
><br>
> Good point.<br>
><br>
><br>
> Why is discriminating particles and fluids desirable here? By the particle_<br>
> naming convention<br>
><br>
> for particle fields there shouldn't be any overlap. I feel that I must have<br>
> missed something.<br>
><br>
><br>
> There has been some talk of moving away from that. (It is an<br>
> Enzo-ism.) Although, looks like in Casey's YTEP for field names, we<br>
> retain them:<br>
><br>
> <a href="https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html" target="_blank">
https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html</a><br>
><br>
> The only issue I was thinking of was that there may be a time when we<br>
> want to do "mass" that applies to both.<br>
><br>
> That being said, as long as we keep "all" as the main name, there's no<br>
> issue. So let's mark my concern as unwarranted.<br>
><br>
><br>
> In a similar vein, I've changed our GeometryHandler._detect_fields function<br>
> to generate all valid<br>
><br>
> (particle_type, field) pairs, so that ("nbody","creation_time") is not a<br>
> valid field, for example, while<br>
><br>
> ("all","particle_mass"), ("nbody","particle_mass"), and<br>
> ("stars","particle_mass") are all valid. This<br>
><br>
> has broken the known field support, however, since we currently only add<br>
> naked field types,<br>
><br>
> without particle types. It would be a pain to need to add all valid pairs<br>
> in fields.py as well.<br>
><br>
><br>
> I agree. I think your solution is right, they should be detected<br>
> correctly in that routine. I'll work on getting the field system<br>
> Chris proposed working, which should be a first step toward fixing the<br>
> valid pairs issue.<br>
><br>
> -Matt<br>
><br>
><br>
> Douglas Rudd<br>
><br>
> Scientific Computing Consultant<br>
><br>
> Research Computing Center<br>
><br>
> <a href="mailto:drudd@uchicago.edu" target="_blank">drudd@uchicago.edu</a><br>
><br>
><br>
><br>
><br>
> On Mar 10, 2013, at 7:21 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br>
><br>
><br>
> I'd rather that not work, to tell the truth. I think Chris's<br>
><br>
> suggestion, where you define a derived field that is neutral to the<br>
><br>
> *type* of particle, is powerful, but I don't see an advantage to it<br>
><br>
> during the call to getting the data, particularly since that loses a<br>
><br>
> bit of ability to discriminate between particles/fluids.<br>
><br>
><br>
> On Sun, Mar 10, 2013 at 8:14 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>><br>
> wrote:<br>
><br>
> Just to clarify, dd[…, "ParticleMassMsun"] would work as well, right?<br>
><br>
><br>
> On Mar 10, 2013, at 5:05 PM, Christopher Moody <<a href="mailto:chrisemoody@gmail.com" target="_blank">chrisemoody@gmail.com</a>><br>
><br>
> wrote:<br>
><br>
><br>
> Hi Sam,<br>
><br>
> Yeah; I think it should change only the derived field. You want the derived<br>
><br>
> field to pass along whatever field type you asked for, or use the implicit<br>
><br>
> one if you didn't ask for the type explicitly. If you tried to implement<br>
><br>
> this in the original call, you'd do something like<br>
><br>
> dd[(Ellipsis,"ParticleMassMsun")]. I can't see use cases where this would<br>
><br>
> be better than dd[("all","ParticleMassMsun")] -- so yeah, no changes to the<br>
><br>
> original call.<br>
><br>
><br>
> chris<br>
><br>
><br>
><br>
> On Sun, Mar 10, 2013 at 4:30 PM, Sam Skillman <<a href="mailto:samskillman@gmail.com" target="_blank">samskillman@gmail.com</a>> wrote:<br>
><br>
><br>
> Hi Chris,<br>
><br>
><br>
> Just to be clear, this change would occur in the derived field definition,<br>
><br>
> not the call to get the star ParticleMassMsun itself, correct?<br>
><br>
><br>
> If so, I think something like this, or with a yt-specific term, would be<br>
><br>
> great.<br>
><br>
><br>
> Thanks,<br>
><br>
> Sam<br>
><br>
><br>
><br>
> On Sun, Mar 10, 2013 at 5:20 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
><br>
> wrote:<br>
><br>
><br>
> Hi Chris,<br>
><br>
><br>
> On Sat, Mar 9, 2013 at 4:00 PM, Christopher Moody <<a href="mailto:chrisemoody@gmail.com" target="_blank">chrisemoody@gmail.com</a>><br>
><br>
> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> Fields in yt-3.0 are now defined like (field_type,field_name) but for<br>
><br>
> backwards-compatibility still maintains a field_name -><br>
><br>
> ("all",field_name)<br>
><br>
> mapping. Consider a few use cases:<br>
><br>
><br>
> keys = ["ParticleMassMsun",<br>
><br>
> ("all","ParticleMassMsun"),<br>
><br>
> ("stars","particle_mass"),<br>
><br>
> ("stars","ParticleMassMsun") ]#broken<br>
><br>
><br>
> I think we all have natural expectations for what should happen, but at<br>
><br>
> the<br>
><br>
> moment the last key in the series is broken. particle_mass is a native<br>
><br>
> field, ParticleMassMsun is a derived field:<br>
><br>
><br>
> def _ParticleMassMsun(field, data):<br>
><br>
> return data["particle_mass"]/mass_sun_cgs<br>
><br>
> add_field("ParticleMassMsun", function=_ParticleMassMsun,<br>
><br>
> particle_type=True)<br>
><br>
><br>
> Note that in this case data["particle_mass"] maps to<br>
><br>
> data[("all","particle_mass")] even when I originally asked for<br>
><br>
> dd[("stars","ParticleMassMsun")], which is why things break.<br>
><br>
><br>
> So I propose a syntax where in the derived field definition we can do<br>
><br>
> something like data[(Ellipsis,"ParticleMassMsun")] or alternatively<br>
><br>
> data[(field.field_type,"ParticleMassMsun")]. This ensures that derived<br>
><br>
> fields will work intuitively and be as specific to a field type as they<br>
><br>
> want<br>
><br>
> to be or just pass through whatever field type they may want.<br>
><br>
><br>
><br>
> I like this, but maybe we should use a yt-specific object instead of<br>
><br>
> Ellipsis. This would be very nice and is something I have thought /<br>
><br>
> worried about and been unable to come up with an elegant solution for.<br>
><br>
> Seems like you found one! :)<br>
><br>
><br>
> This week I need to address this for my own work on a simulation with<br>
><br>
> multiple particle types; I'll take a pass at implementing something<br>
><br>
> like this. We're also a bit overdue for a YTEP that details access to<br>
><br>
> multiple fluids and multiples particles. Once some things get off my<br>
><br>
> plate on Tuesday I will make that a priority. Then we can use that as<br>
><br>
> a place to sort of hash this out and how it'll work.<br>
><br>
><br>
> -Matt<br>
><br>
><br>
> Thanks!<br>
><br>
> chris<br>
><br>
><br>
> _______________________________________________<br>
><br>
> yt-dev mailing list<br>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
> _______________________________________________<br>
><br>
> yt-dev mailing list<br>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
><br>
> yt-dev mailing list<br>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
> _______________________________________________<br>
><br>
> yt-dev mailing list<br>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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>
><br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
><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" target="_blank">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>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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" target="_blank">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>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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>
</blockquote>
</div></div></div>
<br>
</div>
<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></blockquote></div><br>