On Tue, Apr 19, 2016 at 7:53 PM, Jonah Miller 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.

There is not just vertex- and cell-centring; centring can be different in each direction. I think of centring in the following way: (1) There is an underlying cell-centred grid, set up the way yt expects it, with the expected relations between refinement levels (2) Variables can be stored either at the cell centres (as is currently expected), or can be offset (shifted to the left) by 1/2 cell in each of the directions x, y, z (3) Thus the data live either in the cell centre, the faces, edges, or vertices. In 3D, there are 2^3 = 8 possibilities. -erik -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/

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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org