Hey Matt,
The variables I need are the corners of the bounding box (which I call mi, ma, basically left and right edges), number of cells in a grid, grid data itself, children of a grid, and parent of a grid. This data itself works.
I notice children aren't referenced. Is that because everything is defined just in terms of who the parent is, and where the tile exists within the parent? (Which if that's the case, since a top-down traversal is necessary in CUDA, the structure would have to be reversed).
Another thing, I notice that 'dims' and g.ActiveDimensions do not match up a majority of the time. If they don't match up, how do you take a point in space and determine what grid element it maps to? (Trivial, but if these two don't match, I'm not sure who I should trust when doing the computation).
On 3/10/14, 10:59 AM, Matthew Turk wrote:
Hi Alex,
We can have these discussions on yt-dev, too:
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Other people have developed this stuff. You're right, the patches are
(by design) *not* kD-trees. To get kD-trees, you have to use the
.tiles interface, like so:
pf = load(...)
data_source = pf.h.some_object_type(...)
for (g, node, (sl, dims, gi)) in data_source.tiles.slice_traverse():
...
here g is the grid object, node is the node of the kD-tree (for things
like neighbor searching and the like), slice is the slice into the
grid object that defines the node of the kD-tree, dims is the
dimensions of the kD-tree brick, and gi is the left-edge in integers
of the grid object. You can also do traverse, which just iterates and
returns the partitioned grid data and which takesa viewpoint.
-Matt
On Mon, Mar 10, 2014 at 1:45 PM, Alex Bogert <bogart.alex@gmail.com> wrote:
Hi Matt,
I remeber you saying yt can give us AMR in a kd-tree. Was this something
like .get_grids or .get_tiles ?
Thanks,
Alex
On Mar 10, 2014 10:21 AM, "John Holdener" <jrholden@ucsc.edu> wrote:
I'll be in lab shortly near 11. There is a serious complication that I
need to talk to Matt about on the phone (when he gets time). I've been
playing with patches, which are not kt-trees (there are many elements with
no parent or children). This format would take forever searching every grid
for samples.
Once yt gives me a kt-tree, namely whatever class gives it to me, it
should become just CUDA coding.
Everything will need to be global memory, due to texture count constraints
anyways. I suspect the first images will look awful (until some estimated
interpolation happens). Until we get trees sorted out, AMR is at a
standstill.
Sent from my iPhone
On Mar 10, 2014, at 10:04 AM, Alex Bogert <bogart.alex@gmail.com> wrote:
Any update on AMR?
On Mar 6, 2014 10:18 PM, "John Holdener" <jrholden@ucsc.edu> wrote:
I could buy that. However the number of typos typing Theia is going to
drive me nuts!
On 3/6/14, 3:03 PM, Alex Bogert wrote:
Both Joel and I agree we need a good name for the software. I found
"Theia" goddess of tracing and the origin of all light. The greeks believe
she casted light from their eyes to see the world. Super literal
encapsulation. Im open for suggestions! No more acronyms or anything to do
with what languages we use. I think only programmers appreciate these type
of names :)
--
John R. Holdener
Research Assistant
UCSC HiPACC
jrholden@ucsc.edu
--
John R. Holdener
Research Assistant
UCSC HiPACC
jrholden@ucsc.edu