Field naming proposal
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-s...
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, "
Matt had a proposal to support general grids, and somewhere inbetween that
and what yt does now are logical Cartesian curvilinear / quadralaterial
grids (some people use eta and xi for the coordinate names in 2-d for
these). Should those types of grids be address in the field naming
proposal or Matt's unstructured proposal (technically, these are
structured, but ...)
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
perhaps off topic for this, but should yt know about the type of
discretization for the grid -- i.e. finite-difference vs. finite-volume,
and should that be indicated in the field name somehow? The only place I
see this really coming into play is in creating derived fields -- at the
moment everything is second-order accurate for a finite-volume code, but if
someone has a higher-order code they might care about the accuracy that the
conversions are done to, and perhaps yt should know about the
discretization.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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-s...)
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).
Where proposed naming convention #1 is:
(field_type, " _ 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 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-s... 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, " 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@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@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes). The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing. Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized. Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future? On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization? Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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
_______________________________________________ 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
I actually wasn't thinking about divergence or any difference operation,
but things as simple as converting between conservative and primitive
variables (which many frontends do). At the moment, I don't think that
this is an issue for anyone, but in the (far?) future, if people want to do
higher order conversions, then having a flag that you are dealing with
finite-volume data (perhaps on a field-by-field basis) might be useful.
On Tue, Dec 23, 2014 at 3:23 PM, Nathan Goldbaum
On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes).
The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing.
Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized.
Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future?
On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization?
Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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
_______________________________________________ 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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Dec 23, 2014 at 1:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I actually wasn't thinking about divergence or any difference operation, but things as simple as converting between conservative and primitive variables (which many frontends do). At the moment, I don't think that this is an issue for anyone, but in the (far?) future, if people want to do higher order conversions, then having a flag that you are dealing with finite-volume data (perhaps on a field-by-field basis) might be useful.
I agree -- but I think I'm not sure yet if we want to deal with that on a per-frontend basis, or if we want it to be in the field system itself. Do we want to make an educated, possibly wrong guess, or should we leave more work up to the frontend implementor? I fear in many cases we have erred too far on the side of the former.
On Tue, Dec 23, 2014 at 3:23 PM, Nathan Goldbaum
wrote: On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes).
The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing.
Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized.
Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future?
On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization?
Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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
_______________________________________________ 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
_______________________________________________ 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
probably frontend, but even within a frontend, there may be a spread. For
example, take chombo. At the moment, it computes velocity from momentum
and density simply by dividing, which is second-order accurate in space.
But the chombo group has a 4th-order algorithm (
http://msp.org/camcos/2011/6-1/p01.xhtml -- not sure if this is part of
chombo though), and there, you'd want to do that conversion between
velocity and momentum with the same level of accuracy (which that paper
shows means you have a correction term that looks like a Laplacian).
On Tue, Dec 23, 2014 at 4:11 PM, Matthew Turk
On Tue, Dec 23, 2014 at 1:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I actually wasn't thinking about divergence or any difference operation, but things as simple as converting between conservative and primitive variables (which many frontends do). At the moment, I don't think that this is an issue for anyone, but in the (far?) future, if people want to do higher order conversions, then having a flag that you are dealing with finite-volume data (perhaps on a field-by-field basis) might be useful.
I agree -- but I think I'm not sure yet if we want to deal with that on a per-frontend basis, or if we want it to be in the field system itself. Do we want to make an educated, possibly wrong guess, or should we leave more work up to the frontend implementor? I fear in many cases we have erred too far on the side of the former.
On Tue, Dec 23, 2014 at 3:23 PM, Nathan Goldbaum
wrote: On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes).
The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing.
Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized.
Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future?
On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization?
Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum
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-s...
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, "
_ _<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@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
_______________________________________________ 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
_______________________________________________ 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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Dec 23, 2014 at 1:18 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
probably frontend, but even within a frontend, there may be a spread. For example, take chombo. At the moment, it computes velocity from momentum and density simply by dividing, which is second-order accurate in space. But the chombo group has a 4th-order algorithm ( http://msp.org/camcos/2011/6-1/p01.xhtml -- not sure if this is part of chombo though), and there, you'd want to do that conversion between velocity and momentum with the same level of accuracy (which that paper shows means you have a correction term that looks like a Laplacian).
We could potentially decouple the two, and supply a set of conversion operations, and then allow frontends to decide which to use and in which cases? The way fields are set up this should be supported quite easily. I think we lose considerable value if we become completely neutral to the methods, but we also ought not be making the wrong decision in the presence of better possible decisions. When we set up the initial new field system with plugins, I wanted to make it easy to decide on the "stencil" used. It might be appropriate to provide more options for that, and to even explore the idea of code generation for more complex fields. We already depend on sympy, after all. (Maybe this is what you proposed initially... :)
On Tue, Dec 23, 2014 at 4:11 PM, Matthew Turk
wrote: On Tue, Dec 23, 2014 at 1:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I actually wasn't thinking about divergence or any difference operation, but things as simple as converting between conservative and primitive variables (which many frontends do). At the moment, I don't think that this is an issue for anyone, but in the (far?) future, if people want to do higher order conversions, then having a flag that you are dealing with finite-volume data (perhaps on a field-by-field basis) might be useful.
I agree -- but I think I'm not sure yet if we want to deal with that on a per-frontend basis, or if we want it to be in the field system itself. Do we want to make an educated, possibly wrong guess, or should we leave more work up to the frontend implementor? I fear in many cases we have erred too far on the side of the former.
On Tue, Dec 23, 2014 at 3:23 PM, Nathan Goldbaum
wrote: On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes).
The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing.
Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized.
Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future?
On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization?
Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum < nathan12343@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-s...
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, "
_ _<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@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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
On Tue, Dec 23, 2014 at 1:18 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
probably frontend, but even within a frontend, there may be a spread. For example, take chombo. At the moment, it computes velocity from momentum and density simply by dividing, which is second-order accurate in space. But the chombo group has a 4th-order algorithm ( http://msp.org/camcos/2011/6-1/p01.xhtml -- not sure if this is part of chombo though), and there, you'd want to do that conversion between velocity and momentum with the same level of accuracy (which that paper shows means you have a correction term that looks like a Laplacian).
You could still do that within a frontend. We have to do similar tricks for Enzo data, where the internal energy fields need to be treated in different ways depending on the simulation parameters. See this function for implementation details: https://bitbucket.org/yt_analysis/yt/src/382082c1638f18bf0549d5cc9afc67db124... I think if you wanted to support the fourth-order accurate chombo data, you would need to do similar tricks to switch out between field definitions. Can we steer this conversation back to the original field naming proposal? It would be great if a few devs could give their opinion about which naming scheme we should go with.
On Tue, Dec 23, 2014 at 4:11 PM, Matthew Turk
wrote: On Tue, Dec 23, 2014 at 1:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I actually wasn't thinking about divergence or any difference operation, but things as simple as converting between conservative and primitive variables (which many frontends do). At the moment, I don't think that this is an issue for anyone, but in the (far?) future, if people want to do higher order conversions, then having a flag that you are dealing with finite-volume data (perhaps on a field-by-field basis) might be useful.
I agree -- but I think I'm not sure yet if we want to deal with that on a per-frontend basis, or if we want it to be in the field system itself. Do we want to make an educated, possibly wrong guess, or should we leave more work up to the frontend implementor? I fear in many cases we have erred too far on the side of the former.
On Tue, Dec 23, 2014 at 3:23 PM, Nathan Goldbaum
wrote: On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Matt had a proposal to support general grids, and somewhere inbetween that and what yt does now are logical Cartesian curvilinear / quadralaterial grids (some people use eta and xi for the coordinate names in 2-d for these). Should those types of grids be address in the field naming proposal or Matt's unstructured proposal (technically, these are structured, but ...)
I think this is unrelated (but Matt please feel free to jump in if you think this field naming discussion has any bearing on support for unstructured meshes).
The proposal establishes a standard naming convention for vector fields in curvilinear coordinates. If people want to use alternate naming conventions, perhaps it's enough that they can create new alias fields with their preferred names? I'm not sure how far down the road of support for alternative curvilinear naming conventions we need to build in to yt itself, since that will easily get complicated and confusing.
Fields exist at a high conceptual layer in yt where ideally a user doesn't need to know anything about the underlying discretization. When I ask for the radial coordinate of the of the gas velocity vector for a set of cells, I don't necessarily care how those cells are discretized.
Do you have am example where the proposed field naming system would be awkward to work with for some data that we would like to support in the future?
On Tue, Dec 23, 2014 at 11:54 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
perhaps off topic for this, but should yt know about the type of discretization for the grid -- i.e. finite-difference vs. finite-volume, and should that be indicated in the field name somehow? The only place I see this really coming into play is in creating derived fields -- at the moment everything is second-order accurate for a finite-volume code, but if someone has a higher-order code they might care about the accuracy that the conversions are done to, and perhaps yt should know about the discretization.
I'm not sure whether this should show up in the field names. Can you sketch out an example where it would be useful to know the underlying discretization?
Are you thinking of fields like velocity divergence, where we need to use a stencil to compute the derived field? If that's the case, I think that should be implemented using multiple dispatch for python field implementation functions. In this approach, the implementation for a field gets determined at runtime based on the underlying data format. We do something similar where we swap out definitions for the energy fields for codes that conserve either total energy or internal energy.
On Tue, Dec 23, 2014 at 2:01 PM, Nathan Goldbaum < nathan12343@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-s...
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, "
_ _<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@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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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. 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") 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _
_<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
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-s...
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, "
_ _<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@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@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
On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _
_<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
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-s...
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, "
_ _<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@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@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
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
On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _
_<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
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-s...
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, "
_ _<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@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@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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
wrote: On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _
_<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@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-s...
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, "
_ _<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@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@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
_______________________________________________ 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
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
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
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
wrote: On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _
_<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@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-s...
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, "
_ _<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@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@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
_______________________________________________ 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
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
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
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
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
wrote: On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _ _<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@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-s... > > 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, "
_ _<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@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@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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
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
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
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
wrote:
On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: Hi Cameron,
On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
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-s...) > 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, "
_ _ _<coordinate>") > e.g. ('all', 'particle_position_spherical_phi') > > Proposed naming convention #2 is: > > (field_type, " _ >_ _<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@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-s... >> >> 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, " _ _<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@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@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
_______________________________________________ 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
_______________________________________________ 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
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.
On Jan 3, 2015, at 5:30 PM, Andrew Myers
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
mailto:nathan12343@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
mailto:bthompson2090@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
mailto:samskillman@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
mailto:brittonsmith@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
mailto:nathan12343@gmail.com> wrote: On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
mailto:matthewturk@gmail.com> wrote: Hi Cameron, On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels
mailto:chummels@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-s... https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-s...) 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, "
_ _ _<coordinate>") e.g. ('all', 'particle_position_spherical_phi') Proposed naming convention #2 is:
(field_type, "
_ _ _<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
mailto:nathan12343@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-s... https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-s...
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, "
_ _<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 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@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org http://chummels.org/ _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-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
On Sun, Jan 4, 2015 at 2:56 PM, John ZuHone
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...
On Jan 3, 2015, at 5:30 PM, Andrew Myers
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
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
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
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
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@gmail.com> wrote:
On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
wrote: > Hi Cameron, > > On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels < > chummels@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-s...) >> 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, "
_ _ _<coordinate>") >> e.g. ('all', 'particle_position_spherical_phi') >> >> Proposed naming convention #2 is: >> >> (field_type, " _ > >_ _<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@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-s... >>> >>> 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, " _ _<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@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@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
_______________________________________________ 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
_______________________________________________ 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
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
On Sun, Jan 4, 2015 at 2:56 PM, John ZuHone
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...
On Jan 3, 2015, at 5:30 PM, Andrew Myers
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
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
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
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
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@gmail.com> wrote:
> > > On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk
> wrote: > >> Hi Cameron, >> >> On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels < >> chummels@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-s...) >>> 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, " _ _ _<coordinate>") >>> e.g. ('all', 'particle_position_spherical_phi') >>> >>> Proposed naming convention #2 is: >>> >>> (field_type, " _ >> >_ _<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@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-s... >>>> >>>> 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, " _ _<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@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@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 > > _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@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
I'm ok with resuming normal operations this week.
On Sun, Jan 4, 2015 at 6:46 PM, Cameron Hummels
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
wrote: On Sun, Jan 4, 2015 at 2:56 PM, John ZuHone
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...
On Jan 3, 2015, at 5:30 PM, Andrew Myers
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
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
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
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@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@gmail.com> wrote: > >> >> >> On Tue, Dec 23, 2014 at 1:33 PM, Matthew Turk < >> matthewturk@gmail.com> wrote: >> >>> Hi Cameron, >>> >>> On Tue, Dec 23, 2014 at 11:56 AM, Cameron Hummels < >>> chummels@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-s...) >>>> 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, "
_ _ _<coordinate>") >>>> e.g. ('all', 'particle_position_spherical_phi') >>>> >>>> Proposed naming convention #2 is: >>>> >>>> (field_type, " _ >>> >_ _<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@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-s... >>>>> >>>>> 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, " _ _<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@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@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 >> >> > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (9)
-
Andrew Myers
-
Ben Thompson
-
Britton Smith
-
Cameron Hummels
-
John ZuHone
-
Matthew Turk
-
Michael Zingale
-
Nathan Goldbaum
-
Sam Skillman