[yt-dev] vertex-centered data

[Matthew Turk]

Hi Jonah,

The to_centering is something I'd thought about, and which I think
would be useful.  But I think what we're getting a bit closer to is an
ontology for field types.  Mike and Erik pointed out some other
possibilities as well.  What I'd like to see is a method of thinking
about some of the more obvious types and tying the visualization and
averaging methods for these closer to the type.  For example:

 * Cell
 * Vertex
 * Edge (in each dimension)
 * Face (in each dimension)
 * Discrete point
 * Smoothed point

This is just for structured and particle data.  For finite element
data (which, I believe, the vertex-centered data *could* be
represented as, as-is, but which would be slower since it makes no
assumptions about the structure of the data) there is a host of
options for how the data definition works.

I think coming up with a field definition that can be utilized in a
more systematic way (and potentially pushed down to a lower level than
Python) for things like averaging, pixelizing, and so on, would be
very useful.

-Matt

On Tue, Apr 19, 2016 at 6:53 PM, Jonah Miller
<jonah.maxwell.miller at gmail.com> wrote:
> Hi yt-dev,
>
> Nathan Goldbaum and I were discussing the possibility of handling
> vertex-centered data natively in yt. We think that roughly this is quite
> do-able and that most of the pieces are already in place. Nathan suggested I
> summarize our discussion and email it to all of you to ask for your
> opinions.
>
> Internally, all that's required is using the generated ghost cells to
> convert between cell- and vertex-centered data. (For non-periodic
> boundaries, linear extrapolation, which would need to be implemented, should
> be good enough.)
>
> In the userspace side, we need a concept for this type of data so that it
> can be extracted and manipulated. One option would be to make centering an
> attribute for datasets. It could be immutable or mutable, depending on
> design choices. In both cases, we would create a method to go between
> centerings:
> ds.to_centering(centering_type)
>
> in the former case, this method would return a new dataset. In the latter
> case, it would reset the dataset.
>
> In principle, centering is a metadata property. The input data can be
> interpolated when it's explored and not before. So for this reason, it makes
> some sense to leave the centering as a dataset property rather than as, say,
> a field property.
>
> I think that's about it. Nathan can correct me if I forgot something.
>
> Thanks!
>
> Best,
> Jonah Miller
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org