Vertex-centred AMR data?
I have implemented a front-end for cell-centred Cactus AMR data. 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.
-erik
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 javascript:_e(%7B%7D,'cvml','schnetter@gmail.com');> http://www.perimeterinstitute.ca/personal/eschnetter/
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 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
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,
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 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
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,
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 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
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 matthewturk@gmail.com 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,
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 <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
Hi Erik,
OK -- here are the changes that will need to be made. For a stopgap, your AMRGridPatch subclass should call select_cells such that the values computed by LeftEdge + 0.5dx + i*dx are the vertex centered points. For longer term, this will be a selection routine that is called "select_vertices" which does the math internally; this is placed in yt/geometry/selection_routines.pyx . This will ensure that the
The next step is ensuring that the notion of a "volume" is meaningful. Typically this is computed by taking the product of fwidth, which is the "spatial extent" in all three dimensions of each point. This is where the impedance mismatch will be the most difficult, because either each vertex will need to be part of a cell, or it will need to be regarded as its principle "extent", i.e., the domain over which is it considered "valid."
The final step is going to be modifying the pixelization routine to recognize vertex centered data. This is probably the easiest, as I suspect that it will work reasonably well out of the box as-is.
The second step is the one that is the most troublesome, as I think it will be necessary to ensure that fwidth is not used elsewhere in a way that doesn't make sense for vertex-centered data. One of the reasons I would be most careful with this is that the notion of masking and overlapping vertices means not all vertices will have the same conceptual "width." For instance, at coarse-fine boundaries.
On Wed, Nov 11, 2015 at 8:55 AM, Erik Schnetter schnetter@gmail.com wrote:
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 matthewturk@gmail.com 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,
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 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
-- 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
participants (3)
-
Erik Schnetter -
Matthew Turk -
Nathan Goldbaum