Thanks, this helps. This means that for the specific case of your
data, we will need to use a different selection method than that used
for finite element data, where we select full cells rather than
allowing partial selection. Instead of "rounding up" we should be
using a method similar to particle selection, where discrete points
For the case of changing a set of points into a pixel buffer, this
means we will use nearest-neighbor interpolation (with no sub-cellular
interpolation). This should be straightforward, as it will suffice to
define an edge of a zone (which will be truncated at boundaries) and
width, which we do already for cell-centered data.
On Wed, Nov 11, 2015 at 8:50 AM, Erik Schnetter <email@example.com> wrote:
> In my notion, there are no cells, only vertices. Or if you want to renaming
> things, then there are only cells, no vertices, but the fine a coarse grid
> cells do not share faces.
> To answer your question specifically: no, it does not matter whether the
> centre of a "cell" is selected. Only the vertices that are selected should
> be part of the selection.
> On Wed, Nov 11, 2015 at 8:57 AM, Matthew Turk <firstname.lastname@example.org> wrote:
>> Hi Erik,
>> I have some ideas about this, but it relies heavily on the notion of
>> how to regard "vertices" as separate from "cells", or if they should
>> not be. In terms of things like visualization, vertex centered data
>> is not a huge leap in functionality, but in terms of data selection we
>> need to be careful. The canonical question is, if you have a region
>> selector that includes the *center* of a zone, should all of its
>> vertices be selected? For instance, imagine you have a region
>> selector whose corner resides at the center of a (3D) cell. Does one
>> select all eight vertices, since the "cell" is nominally selected, or
>> just the one vertex that is included? If we can answer that, we can
>> start the work of implementing.
>> On Tue, Nov 10, 2015 at 7:11 PM, Nathan Goldbaum <email@example.com>
>> > On Tuesday, November 10, 2015, Erik Schnetter <firstname.lastname@example.org>
>> > wrote:
>> >> I have implemented a front-end for cell-centred Cactus AMR data.
>> > Awesome! We'd love to have this in the public distribution of yt.
>> >> However, many Cactus simulations use vertex-centred AMR. That is, data
>> >> is
>> >> stored at the vertices of a grid (not in the cells), and coarse
>> >> vertices are
>> >> at the same locations as fine vertices.
>> >> How do I present such data to yt? Do I need to set grid coordinates
>> >> differently, or is there a "vertex centred" flag?
>> >> When vertex-centred data are displayed, then I expect either a "control
>> >> volume" around each vertex to have the same value, or to use e.g.
>> >> linear
>> >> interpolation in the cells from the respective boundaries.
>> > We don't have good support for vertex-centered AMR data. I think Matt
>> > would
>> > have a better idea of what approaches we might take here.
>> >> -erik
>> >> --
>> >> Erik Schnetter <email@example.com>
>> >> http://www.perimeterinstitute.ca/personal/eschnetter/
>> > _______________________________________________
>> > yt-dev mailing list
>> > firstname.lastname@example.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> yt-dev mailing list
> Erik Schnetter <email@example.com>
> yt-dev mailing list
yt-dev mailing list