[yt-dev] New default particle union?

Wed Mar 29 15:58:10 PDT 2017

Ok, that would be pretty easy to customize in the Boxlib frontend (or any
other frontends that have tracer particles).

Do we have any public test datasets with tracer particles?

On Wed, Mar 29, 2017 at 5:56 PM Michael Zingale <
michael.zingale at stonybrook.edu> wrote:

> yes, passive are just lagrangian tracer particles.  So, for example, all
> of the particle stuff in Castro and Maestro are passive / tracer particles,
> and should probably not get an "n-body" label.
>
> On Wed, Mar 29, 2017 at 6:53 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
> Sorry, you're using terminology I'm unfamiliar with. Are passive particles
> the same thing as tracer particles? If so I agree they should probably be
> considered separately from n-body particles. For the derived quantities
> that motivated this example, massless particles would also need to be
> neglected.
>
> On Wed, Mar 29, 2017 at 5:40 PM Michael Zingale <
> michael.zingale at stonybrook.edu> wrote:
>
> I think the name n-body only makes sense for datasets with active
> particles, not those with passive particles.  The latter are the ones that
> I typically deal with.  So maybe a different name?  or maybe a way for a
> code to register if it is using active or passive particles?
>
> On Wed, Mar 29, 2017 at 5:36 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>
>
> On Wed, Mar 29, 2017 at 4:33 PM, Cameron Hummels <chummels at gmail.com>
> wrote:
>
> Wait, so we'd have both an 'all' ftype and an 'n-body' ftype and the
> 'n-body' ftype would just include non-gas particles (ie ones without the
> 'smoothing_length' field)?  I'm assuming this won't add more computational
> load when reading in the dataset?
>
>
> I doubt it. There will just be some more fields in ds.derived_field_list
> (one 'n-body' field for each of the 'all' fields).
>
>
> If that's the case, then I'm +0.5 on it.  I haven't had a need for it up
> to this point, but maybe other people really need it?
>
> On Wed, Mar 29, 2017 at 2:21 PM, John ZuHone <jzuhone at gmail.com> wrote:
>
> +1.
>
> "n_body"?
>
> On Mar 29, 2017, at 5:19 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>
> +1, and I think updating YTEP-0031 is sufficient.  Not sure that "n-body"
> specifically is my preference, since it's not tokenizable, but maybe it's
> fine.
>
> On Wed, Mar 29, 2017 at 4:18 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
> Hi all,
>
> I'd like to propose adding a new particle union that should be defined for
> all datasets that include particles. This came up in the context of the
> demeshening work (see
> https://bitbucket.org/yt_analysis/ytep/pull-requests/67 for more details).
>
> Right now many of the derived quantities make a distinction between
> calculating results using just the gas or just the particles or both. Up
> until now they have calculated the results for particles using particle
> fields from the 'all' particle union. This makes perfect sense for AMR data
> but doesn't really make sense for SPH data, since it will double-count SPH
> particles. In fact, I think this is an issue even without the demeshening,
> but the demeshening makes it more starkly apparent.
>
> I'd like to propose defining a new "n-body" particle union (suggestions
> for alternate names are very welcome) that will be defined for all yt
> datasets. This union will be identical to the 'all' particle union for AMR
> data and N-body particle data, but for SPH data will only include the
> particle types that aren't SPH particles (if any). That means the "n-body"
> particle type represents infinitesimal particles but not particles that
> have finite extents (e.g. an SPH particle's smoothing region).
>
> I think this new particle type would probably be generically useful beyond
> just the derived quantities, maybe even more useful than "all". I also kind
> of prefer the name "n-body" to "all" since it more prominently indicates
> that it's associated with particle data.
>
> Please let me know if you have thoughts or suggestions about this
> proposal. I'm happy to draft a YTEP or update YTEP-0031 with more details
> if people want to see that.
>
> -Nathan
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
>
> --
> Cameron Hummels
> NSF Postdoctoral Fellow
> Department of Astronomy
> California Institute of Technology
> http://chummels.org
>
> _______________________________________________
> 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
>
>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
> 11794-3800
> *phone*:  631-632-8225 <(631)%20632-8225>
> *e-mail*: Michael.Zingale at stonybrook.edu
> *web*: http://www.astro.sunysb.edu/mzingale
> github: http://github.com/zingale
>
> _______________________________________________
> 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
>
>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
> 11794-3800
> *phone*:  631-632-8225
> *e-mail*: Michael.Zingale at stonybrook.edu
> *web*: http://www.astro.sunysb.edu/mzingale
> github: http://github.com/zingale
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20170329/2126477f/attachment-0001.htm>