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@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@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@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@gmail.com> wrote:

On Wed, Mar 29, 2017 at 4:33 PM, Cameron Hummels <chummels@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@gmail.com> wrote:

+1.

"n_body"?

On Mar 29, 2017, at 5:19 PM, Matthew Turk <matthewturk@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@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@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

--

Cameron Hummels

NSF Postdoctoral Fellow

Department of Astronomy

California Institute of Technology

http://chummels.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

--

Michael Zingale

Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800

phone:  631-632-8225

e-mail: Michael.Zingale@stonybrook.edu

web: http://www.astro.sunysb.edu/mzingale

github: http://github.com/zingale

_______________________________________________
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

--

Michael Zingale

Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800

phone:  631-632-8225

e-mail: Michael.Zingale@stonybrook.edu

web: http://www.astro.sunysb.edu/mzingale

github: http://github.com/zingale

_______________________________________________
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