[yt-dev] Particle field generation in 3.0

[Matthew Turk]

On Thu, Jul 3, 2014 at 6:50 PM, Cameron Hummels <chummels at gmail.com> wrote:
> Hey Matt,
>
> OK, so we *can* do it, but the question is, does it make sense to do it?  I
> thought it would be more consistent, but I'm not married to the idea.  Do
> you think it's worth the effort of modifying the code?  I'm just trying to
> look ahead to the future to when we have tons of different particle types,
> but maybe this is no big deal, in which case we can leave it as is.

I don't know.

As it stands, someone can at any time change the field types -- it's
pretty easy to add on new ones.  In fact, the entire infrastructure as
is only arbitrarily chooses "deposit", inside the particle_fields.py.
One could just as easily swap that out.  The only reason I'm nervous
is about people who are out there with code already that are using it.

-Matt

>
> Cameron
>
>
> On Thu, Jul 3, 2014 at 7:32 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi Cameron,
>>
>> I'd be fine with this change, but it touches a *lot* of user-facing
>> code already.  If we did this, then inside _determine_fields and all
>> the other places we guess the field names, we'd need backward
>> compatibility.
>>
>> -Matt
>>
>> On Thu, Jul 3, 2014 at 6:21 PM, Cameron Hummels <chummels at gmail.com>
>> wrote:
>> > Hello everyone,
>> >
>> > As I'm updating some of the documentation in 3.0 to be current on field
>> > generation, I thought of something that might make the particle fields a
>> > bit
>> > more clean as we build on them in the future.
>> >
>> > As I understand it, each particle type from a given code will generate
>> > its
>> > own namespace for those native particle quantities.  So for example a
>> > Gadget
>> > binary dataset will read in its star, gas, and DM particles as:
>> >
>> > ('star', 'particle_mass')
>> > ('gas', 'particle_mass')
>> > ('DM', 'particle_mass')
>> >
>> > but when these different particles are deposited and smoothed on to the
>> > grid, they all get put into the same 'deposit' namespace:
>> >
>> > ('deposit', 'star_density')
>> > ('deposit', 'gas_density')
>> > ('deposit', 'DM_density')
>> >
>> > It seems to me that perhaps we should create a separate deposit
>> > namespace
>> > for each of the native particle types, so that we'll have a clean 1-to-1
>> > conversion between native particle types and smoothed particle types in
>> > namespaces.  Now the above fields would map to:
>> >
>> > ('deposit_star', 'density')
>> > ('deposit_gas', 'density')
>> > ('deposit_DM', 'density')
>> >
>> > This doesn't seem like it would be hard to change in the
>> > field-generation
>> > infrastructure, but it might break things later on, which I've just not
>> > yet
>> > considered.  Anyway, I just wanted to bounce this off of people.  It may
>> > not
>> > be better in the long run, but it seemed like if we're breaking API, it
>> > should be done now instead of later on.  I may be missing something big
>> > here, but I wanted to see what others thought.
>> >
>> > Cameron
>> >
>> > --
>> > Cameron Hummels
>> > Postdoctoral Researcher
>> > Steward Observatory
>> > University of Arizona
>> > 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
>
>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>