[yt-dev] Field naming proposal

Britton Smith brittonsmith at gmail.com
Mon Jan 5 09:20:07 PST 2015 

I'm ok with resuming normal operations this week.

On Sun, Jan 4, 2015 at 6:46 PM, Cameron Hummels <chummels at gmail.com> wrote:

> Yeah, that sounds good, Nathan.  I think we're probably mostly ready to go
> with this, but I know Britton wanted to hold off on this until people were
> back at their desks in January, which is basically this week.  I'd say
> update your PR as you need to, but don't yet merge, but I think your naming
> scheme is the way to go.  Sound OK?
>
> On Sun, Jan 4, 2015 at 3:09 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Jan 4, 2015 at 2:56 PM, John ZuHone <jzuhone at gmail.com> wrote:
>>
>>> I think that the fact that we have two equally fairly complex naming
>>> schemes here is a sign that we need to have a better way of organizing
>>> fields in different coordinate systems, but in the absence of a clear
>>> proposal for this I guess I would go with Option #1.
>>>
>>
>> Well they're basically the same, just different a small difference in
>> ordering.
>>
>> Matt had an idea earlier in the thread based on context managers, but I'm
>> not sure how that would necessarily ease accessing these fields, since we
>> need to name them somehow, and asking for the 0th basis vector in the
>> cylindical polar coordinate system is a bit less satisfying (to me) than
>> asking for the cylindrical_radius component.
>>
>> OK, so that's 5 votes in favor of my proposed naming scheme.  Would it be
>> ok for me to update my open PR to implement the rest of the naming scheme?
>>
>>
>> https://bitbucket.org/yt_analysis/yt/pull-request/1381/particle-position-and-velocity-fields-for/diff
>>
>>
>>>
>>> On Jan 3, 2015, at 5:30 PM, Andrew Myers <atmyers2 at gmail.com> wrote:
>>>
>>> I think both conventions are good, but I slightly prefer #1 (Nathan's
>>> naming) for being closer to what is done for Cartesian vector fields.
>>>
>>> On Sat, Jan 3, 2015 at 11:03 AM, Nathan Goldbaum <nathan12343 at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Since this is one of the blockers for 3.1, I'd like to bump this
>>>> thread.  It looks like we're now at 3 votes for my proposal and 2 votes for
>>>> Cameron's proposal.
>>>>
>>>> It would be great if a few more people could weigh in.  Take a look at
>>>> Cameron's e-mail near the top of this thread if you need a reminder.
>>>>
>>>> -Nathan
>>>>
>>>> On Mon, Dec 29, 2014 at 1:52 PM, Ben Thompson <bthompson2090 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hey all.
>>>>>
>>>>> Nathan, thank you for setting this up, Cameron thank you for clearly
>>>>> outlining the naming conventions, and sorry to you all if I have been a bit
>>>>> quiet recently.
>>>>>
>>>>> I am for option #1 which to me feels a bit more natural to go particle
>>>>> -> vector field -> coordinate system -> coordinate
>>>>>
>>>>> As Britton has said, it would be best to finalise a decision in the
>>>>> new year (maybe at the end of the first full week? say the 8th?).
>>>>>
>>>>> This PR in question also corrects numerical computation in the
>>>>> particle_spherical co-ordinate system too as well as updatin the field
>>>>> naming YTEP, so is also important to get out in it's own right.
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 24, 2014 at 5:14 AM, Sam Skillman <samskillman at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all, I agree with Britton here that it would be good to table this
>>>>>> until folks have time to read through this carefully. Thanks, Sam
>>>>>>
>>>>>>
>>>>>> On Tue Dec 23 2014 at 2:40:41 PM Britton Smith <
>>>>>> brittonsmith at gmail.com> wrote:
>>>>>>
>>>>>>> I choose option #1.
>>>>>>>
>>>>>>> Also, let's not be too quick to make big decisions here.  Many
>>>>>>> people are on break right now and so are unavailable, or are wanting to be.
>>>>>>>
>>>>>>> On Tue, Dec 23, 2014 at 3:42 PM, Nathan Goldbaum <
>>>>>>> nathan12343 at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk <
>>>>>>>> matthewturk at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Cameron,
>>>>>>>>>
>>>>>>>>> On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels <
>>>>>>>>> chummels at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Nathan,
>>>>>>>>>>
>>>>>>>>>> Thanks for your hard work on this PR (along with Ben Thompson).
>>>>>>>>>> The naming convention that I suggested in the issue a few weeks back (
>>>>>>>>>> https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-spherical-and)
>>>>>>>>>> and in the discussion on your PR also matches with past convention.  It is
>>>>>>>>>> slightly different than what you propose, but seems (to me at least) to be
>>>>>>>>>> more easy to read because the adjective comes before the noun (e.g.
>>>>>>>>>> spherical position) instead of the reverse (e.g. position spherical).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I'm neutral to both of these, in that I am broadly neutral about
>>>>>>>>> the increasingly nested set of modifiers.  If forced, I think I'd go with
>>>>>>>>> your proposed convention.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's two votes against my convention (Cameron and Matt).  If no
>>>>>>>> one else pipes up in favor of my convention in the next day or so, I'll go
>>>>>>>> ahead and create a YTEP PR and update my PR to match.  This means we need
>>>>>>>> to deprecate fewer fields, so it's probably simpler in the end...
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What would be a lot nicer, in my opinion, would be if we had a way
>>>>>>>>> to do this more generically.  Like,
>>>>>>>>>
>>>>>>>>> with data_object.rotate( ... ):
>>>>>>>>>     prof1d = create_profile(data_object, "particle_position_x",
>>>>>>>>> "particle_mass")
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is a much nicer syntax.  We should consider this for a future
>>>>>>>> release.  If someone puts together a prototype for using data objects with
>>>>>>>> context managers like this, I think we can have a big usability win for a
>>>>>>>> lot of use cases.
>>>>>>>>
>>>>>>>> Unfortunately we would probably still need to accept the names with
>>>>>>>> modifiers for backward compatibility.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> and then just get rid of all the nested modified field names.  But
>>>>>>>>> I don't really think this is feasible.
>>>>>>>>>
>>>>>>>>> -Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Where proposed naming convention #1 is:
>>>>>>>>>>
>>>>>>>>>> (field_type, "<particle?>_<position/velocity>_<coordinate_system>_<coordinate>")
>>>>>>>>>> e.g. ('all', 'particle_position_spherical_phi')
>>>>>>>>>>
>>>>>>>>>> Proposed naming convention #2 is:
>>>>>>>>>>
>>>>>>>>>> (field_type, "<particle?>_<coordinate_system
>>>>>>>>>> >_<position/velocity>_<coordinate>") e.g. ('all',
>>>>>>>>>> 'particle_spherical_position_phi')
>>>>>>>>>>
>>>>>>>>>> Here are all of the relevant gas and particle fields each
>>>>>>>>>> convention:
>>>>>>>>>>
>>>>>>>>>> *Cartesian* (convention #1 & #2 are the same)
>>>>>>>>>>
>>>>>>>>>> ('index', 'x')
>>>>>>>>>> ('index', 'y')
>>>>>>>>>> ('index', 'z')
>>>>>>>>>> ('gas', 'velocity_x')
>>>>>>>>>> ('gas', 'velocity_y')
>>>>>>>>>> ('gas', 'velocity_z')
>>>>>>>>>>
>>>>>>>>>> ('all', 'particle_position_x')
>>>>>>>>>> ('all', 'particle_position_y')
>>>>>>>>>> ('all', 'particle_position_z')
>>>>>>>>>> ('all', 'particle_velocity_x')
>>>>>>>>>> ('all', 'particle_velocity_y')
>>>>>>>>>> ('all', 'particle_velocity_z')
>>>>>>>>>>
>>>>>>>>>> Convention #1 & #2 differ for the fields of cartesian position
>>>>>>>>>> relative to the 'center' and 'normal' field parameters for the origin and
>>>>>>>>>> z-vector:
>>>>>>>>>>
>>>>>>>>>> #1 vs #2
>>>>>>>>>> ('all', 'particle_position_relative_x')  vs. ('all',
>>>>>>>>>> 'particle_relative_position_x')
>>>>>>>>>> ('all', 'particle_position_relative_y')  vs. ('all',
>>>>>>>>>> 'particle_relative_position_y')
>>>>>>>>>> ('all', 'particle_position_relative_z')  vs. ('all',
>>>>>>>>>> 'particle_relative_position_z')
>>>>>>>>>> ('all', 'particle_velocity_relative_x')  vs. ('all',
>>>>>>>>>> 'particle_velocity_position_x')
>>>>>>>>>> ('all', 'particle_velocity_relative_y')  vs. ('all',
>>>>>>>>>> 'particle_velocity_position_y')
>>>>>>>>>> ('all', 'particle_velocity_relative_z')  vs. ('all',
>>>>>>>>>> 'particle_velocity_position_z')
>>>>>>>>>>
>>>>>>>>>> *Spherical*:
>>>>>>>>>> #1 vs #2
>>>>>>>>>>
>>>>>>>>>> ('index', 'spherical_phi')
>>>>>>>>>> ('index', 'spherical_radius')
>>>>>>>>>> ('index', 'spherical_theta')
>>>>>>>>>> ('gas', 'velocity_spherical_phi') vs      ('gas',
>>>>>>>>>> 'spherical_velocity_phi')
>>>>>>>>>> ('gas', 'velocity_spherical_theta') vs   ('gas',
>>>>>>>>>> 'spherical_velocity_theta')
>>>>>>>>>> ('gas', 'velocity_spherical_radius') vs ('gas',
>>>>>>>>>> 'spherical_velocity_radius')
>>>>>>>>>>
>>>>>>>>>> ('all', 'particle_position_spherical_phi') vs      ('all',
>>>>>>>>>> 'particle_spherical_position_phi')
>>>>>>>>>> ('all', 'particle_position_spherical_theta') vs   ('all',
>>>>>>>>>> 'particle_spherical_position_theta')
>>>>>>>>>> ('all', 'particle_position_spherical_radius') vs ('all',
>>>>>>>>>> 'particle_spherical_position_radius')
>>>>>>>>>> ('all', 'particle_velocity_spherical_phi') vs       ('all',
>>>>>>>>>> 'particle_spherical_velocity_phi')
>>>>>>>>>> ('all', 'particle_velocity_spherical_theta') vs    ('all',
>>>>>>>>>> 'particle_spherical_velocity_theta')
>>>>>>>>>> ('all', 'particle_velocity_spherical_radius') vs  ('all',
>>>>>>>>>> 'particle_spherical_velocity_radius')
>>>>>>>>>>
>>>>>>>>>> *Cylindrical*:
>>>>>>>>>> #1 vs #2
>>>>>>>>>>
>>>>>>>>>> ('index', 'cylindrical_phi')
>>>>>>>>>> ('index', 'cylindrical_radius')
>>>>>>>>>> ('index', 'cylindrical_theta')
>>>>>>>>>> ('gas', 'velocity_cylindrical_phi') vs      ('gas',
>>>>>>>>>> 'cylindrical_velocity_phi')
>>>>>>>>>> ('gas', 'velocity_cylindrical_theta') vs   ('gas',
>>>>>>>>>> 'cylindrical_velocity_theta')
>>>>>>>>>> ('gas', 'velocity_cylindrical_radius') vs ('gas',
>>>>>>>>>> 'cylindrical_velocity_radius')
>>>>>>>>>>
>>>>>>>>>> ('all', 'particle_position_cylindrical_phi') vs      ('all',
>>>>>>>>>> 'particle_cylindrical_position_phi')
>>>>>>>>>> ('all', 'particle_position_cylindrical_theta') vs   ('all',
>>>>>>>>>> 'particle_cylindrical_position_theta')
>>>>>>>>>> ('all', 'particle_position_cylindrical_radius') vs ('all',
>>>>>>>>>> 'particle_cylindrical_position_radius')
>>>>>>>>>> ('all', 'particle_velocity_cylindrical_phi') vs       ('all',
>>>>>>>>>> 'particle_cylindrical_velocity_phi')
>>>>>>>>>> ('all', 'particle_velocity_cylindrical_theta') vs    ('all',
>>>>>>>>>> 'particle_cylindrical_velocity_theta')
>>>>>>>>>> ('all', 'particle_velocity_cylindrical_radius') vs  ('all',
>>>>>>>>>> 'particle_cylindrical_velocity_radius')
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So what does the community think would be the best system here?
>>>>>>>>>>  #1 or #2?  Either way it goes, I think this is a big improvement over the
>>>>>>>>>> previous naming convention that had general inconsistencies.
>>>>>>>>>>
>>>>>>>>>> Cameron
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Dec 23, 2014 at 11:01 AM, Nathan Goldbaum <
>>>>>>>>>> nathan12343 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I've just issued a pull request that bears some developer
>>>>>>>>>>> discussion.
>>>>>>>>>>>
>>>>>>>>>>> Right now yt is a bit of a wild west in terms of the field
>>>>>>>>>>> naming convention for fields that reference a coordinate system.  See for
>>>>>>>>>>> example, see issue 947:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-spherical-and
>>>>>>>>>>>
>>>>>>>>>>> I'd like to propose a naming convention for fields that
>>>>>>>>>>> reference a coordinate system.  Gas and particle fields should be of the
>>>>>>>>>>> form:
>>>>>>>>>>>
>>>>>>>>>>> (field_type, "<particle?>_<vector_field_name>_<coordinate>")
>>>>>>>>>>>
>>>>>>>>>>> while index fields for coordinates should be of the form:
>>>>>>>>>>>
>>>>>>>>>>> ("index", "<coordinate>")
>>>>>>>>>>>
>>>>>>>>>>> This fits within our existing field naming convention for
>>>>>>>>>>> cartesian coordinates, e.g.:
>>>>>>>>>>>
>>>>>>>>>>> ("gas", "velocity_x")
>>>>>>>>>>> (ptype, "particle_velocity_y")
>>>>>>>>>>>
>>>>>>>>>>> as well as our convention for index coordinate fields, e.g.:
>>>>>>>>>>>
>>>>>>>>>>> ("index", "x")
>>>>>>>>>>> ("index", "spherical_theta")
>>>>>>>>>>>
>>>>>>>>>>> This means that index fields do not need to explicitly reference
>>>>>>>>>>> themselves as positions.  So we *won't* have field names like:
>>>>>>>>>>>
>>>>>>>>>>> ("index", "position_x")
>>>>>>>>>>>
>>>>>>>>>>> I don't like the above construction because it's a bit redundant
>>>>>>>>>>> ("index" implies that we are talking about a position or something similar).
>>>>>>>>>>>
>>>>>>>>>>> Some existing field names will need to be changed to fit this.
>>>>>>>>>>> In particular, some of the index fields will need to be renamed to be more
>>>>>>>>>>> verbose ("index", "spherical_r") becomes ("index", "spherical_radius") and
>>>>>>>>>>> (ptype, "particle_spherical_position_radius") becomes (ptype,
>>>>>>>>>>> "particle_position_spherical_radius").
>>>>>>>>>>>
>>>>>>>>>>> Wherever an existing field name needs to change, I propose we
>>>>>>>>>>> mark the existing field name for deprecation, stub it out, and make it an
>>>>>>>>>>> alias for the field with the new field name.  In a future release, we can
>>>>>>>>>>> then remove the deprecated fields.
>>>>>>>>>>>
>>>>>>>>>>> I've implemented this for the particle fields (for the most
>>>>>>>>>>> part) in PR 1378:
>>>>>>>>>>>
>>>>>>>>>>> https://bitbucket.org/yt_analysis/yt/pull-request/1378
>>>>>>>>>>>
>>>>>>>>>>> I'm happy to update the field naming YTEP if this proposed field
>>>>>>>>>>> naming scheme gets approval in this thread.
>>>>>>>>>>>
>>>>>>>>>>> What do you all think?  Question, concerns?
>>>>>>>>>>>
>>>>>>>>>>> -Nathan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150105/fd95880b/attachment.html>

More information about the yt-dev mailing list