[yt-dev] New default particle union?

Mon Apr 3 10:12:20 PDT 2017

Sorry, late to the party. +1, even nbody is ok with me.

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

> I think Andrew made some recently.  The caveat is that some BoxLib / AMReX
> codes do have active particles, Nyx for example.  So it needs to be done at
> the code-level within the BoxLib/AMReX frontend.
>
> On Wed, Mar 29, 2017 at 6:58 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>> 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 <(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 <(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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20170403/329ac5fd/attachment-0001.htm>