[yt-dev] Field naming proposal

Tue Dec 23 13:10:07 PST 2014

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 <nathan12343 at gmail.com>
wrote:

> On Tue, Dec 23, 2014 at 11:47 AM, Michael Zingale <
> michael.zingale at 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 at 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 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've just issued a pull request that bears some developer discussion.
>>>
>>> Right now yt is a bit of a wild west in terms of the field naming
>>> convention for fields that reference a coordinate system.  See for example,
>>> see issue 947:
>>>
>>>
>>> https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-spherical-and
>>>
>>> I'd like to propose a naming convention for fields that reference a
>>> coordinate system.  Gas and particle fields should be of the form:
>>>
>>> (field_type, "<particle?>_<vector_field_name>_<coordinate>")
>>>
>>> while index fields for coordinates should be of the form:
>>>
>>> ("index", "<coordinate>")
>>>
>>> This fits within our existing field naming convention for cartesian
>>> coordinates, e.g.:
>>>
>>> ("gas", "velocity_x")
>>> (ptype, "particle_velocity_y")
>>>
>>> as well as our convention for index coordinate fields, e.g.:
>>>
>>> ("index", "x")
>>> ("index", "spherical_theta")
>>>
>>> This means that index fields do not need to explicitly reference
>>> themselves as positions.  So we *won't* have field names like:
>>>
>>> ("index", "position_x")
>>>
>>> I don't like the above construction because it's a bit redundant
>>> ("index" implies that we are talking about a position or something similar).
>>>
>>> Some existing field names will need to be changed to fit this.  In
>>> particular, some of the index fields will need to be renamed to be more
>>> verbose ("index", "spherical_r") becomes ("index", "spherical_radius") and
>>> (ptype, "particle_spherical_position_radius") becomes (ptype,
>>> "particle_position_spherical_radius").
>>>
>>> Wherever an existing field name needs to change, I propose we mark the
>>> existing field name for deprecation, stub it out, and make it an alias for
>>> the field with the new field name.  In a future release, we can then remove
>>> the deprecated fields.
>>>
>>> I've implemented this for the particle fields (for the most part) in PR
>>> 1378:
>>>
>>> https://bitbucket.org/yt_analysis/yt/pull-request/1378
>>>
>>> I'm happy to update the field naming YTEP if this proposed field naming
>>> scheme gets approval in this thread.
>>>
>>> What do you all think?  Question, concerns?
>>>
>>> -Nathan
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
>>
>> --
>> Michael Zingale
>> Associate Professor
>>
>> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>> 11794-3800
>> *phone*:  631-632-8225
>> *e-mail*: Michael.Zingale at stonybrook.edu
>> *web*: http://www.astro.sunysb.edu/mzingale
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>

-- 
Michael Zingale
Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
11794-3800
*phone*:  631-632-8225
*e-mail*: Michael.Zingale at stonybrook.edu
*web*: http://www.astro.sunysb.edu/mzingale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20141223/da36c21c/attachment.htm>
-------------- next part --------------
_______________________________________________
yt-dev mailing list
yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org