Matt

For the moment, anything that works would be fine. I always selecting full cells is easier I'd be happy to try this first.

-erik

On Wed, Nov 11, 2015 at 9:53 AM, Matthew Turk wrote:
Hi Erik,

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
are sampled.

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 <schnetter@gmail.com> wrote:
> Matt
>
> 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.
>
> -erik
>
> On Wed, Nov 11, 2015 at 8:57 AM, Matthew Turk <matthewturk@gmail.com> wrote:
>>
>> Hi Erik,
>>
>> 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 <nathan12343@gmail.com>
>> wrote:
>> >
>> >
>> > On Tuesday, November 10, 2015, Erik Schnetter <schnetter@gmail.com>
>> > 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 <schnetter@gmail.com>
>> >> http://www.perimeterinstitute.ca/personal/eschnetter/
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev@lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
>
> --
> Erik Schnetter <schnetter@gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

--