Re: [yt-dev] New default particle union?

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 wrote:

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

...

+1.

"n_body"?

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