[yt-dev] Field naming proposal

Matthew Turk matthewturk at gmail.com
Tue Dec 23 13:21:47 PST 2014


On Tue, Dec 23, 2014 at 1:18 PM, Michael Zingale <
michael.zingale at 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 <matthewturk at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Dec 23, 2014 at 1:10 PM, Michael Zingale <
>> michael.zingale at 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 <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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20141223/7230ec66/attachment.html>
-------------- next part --------------
_______________________________________________
yt-dev mailing list
yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org


More information about the yt-dev mailing list