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