[yt-dev] vertex-centered data

[Michael Zingale]

yes, a lot of methods will use a staggered grid for vector data, like the
MAC grids used in incompressible methods for velocity.

On Wed, Apr 20, 2016 at 11:27 AM, Erik Schnetter <schnetter at gmail.com>
wrote:

> On Tue, Apr 19, 2016 at 7: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.
>
> 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 <schnetter at gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
> _______________________________________________
> 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
github: http://github.com/zingale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160420/9b51a836/attachment-0001.html>