<div dir="ltr">Hi Matt,<div style>I think the oct size reduction is great. This means a lot to NMSU-ART where carrying around the oct_tree is 900MB, which will fall to ~200MB afterwards. And getting rid of the mask will mean rewriting some of the ART frontend code, but it doesn't sound like that should be much of a chore for me to do. And of course, the mask was memory-intensive anyway, so replacing this with a more dynamic selection is better for the long term.</div>
<div style><br></div><div style>NMSU-ART isn't a strict octree, but instead starts with a root grid of octs. I have some cython code that explicitly uses the code index to local oct index matching -- it's not clear to me whether this will need updating with this. Regardless, we're still early in yt-3.0 and I don't mind breaking so many things right now. </div>
<div style><br></div><div style>+1 </div><div style><br></div><div style>chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 11:00 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I've shared some of this with ChrisM and SamL, but I wanted to bring<br>
it up here.  This largely pertains to the codes RAMSES and NMSU-ART<br>
that are currently supported, as well as the support for particle<br>
Octrees.  ARTIO is somewhat orthogonal at this time, as it doesn't<br>
store the octree in memory.<br>
<br>
Currently, Octs have:<br>
<br>
int (64-bits)<br>
local_ind (64-bits)<br>
domain (64-bits)<br>
pos[3] (64-bits each)<br>
level (64-bits)<br>
pointer-to-sd (64-bits)<br>
children, 8 pointers (64-bits each)<br>
parent (64-bits)<br>
<br>
This comes out to 136 bytes.  Much of this is because we have two<br>
different methods of traversing the Octs, both in allocation-order and<br>
in depth-first traversal order, and also because when I wrote this<br>
(seems like yesterday) I was trying to get something done without<br>
worrying too much about memory optimization.  However, both of these<br>
things are becoming much more important; firstly, we need to ensure<br>
we're thinking about the memory implications of a large number of leaf<br>
nodes, and we need to verify that order of traversal is not important<br>
-- or at least, is guaranteed identical.<br>
<br>
Last week I spent some time rewriting the traversal code to attempt to<br>
get rid of much of the self-awareness of the octs, such that *outside*<br>
of a traversal, they are somewhat meaningless.  This lets me cut it<br>
down to:<br>
<br>
domain index (which we may be able to eliminate in the future)<br>
code-specific index<br>
allocateable pointer to the 8 children (linearly)<br>
pointer-to-sd object<br>
<br>
This should be 32 bytes for leaf nodes, which expands for non-leaf<br>
nodes, although we may be able to cut that down as well (at the<br>
expense of slight over-allocation for instances when not all cells<br>
must be simultaneously refined.)  I've implemented this with a<br>
traversal object, such that it will track the level state, the oct<br>
state, and so on and so forth.  This works for all of the tests I have<br>
been able to create for it, but it results in a slight performance<br>
decrease.  (I believe in the future we can optimize this.)<br>
<br>
Anyway, here's where I'm going with all of this.  I'd like to extend<br>
the Octree base class, but in a way that leaves several items up to<br>
individual implementations.  Furthermore, I'd like to start a brief<br>
discussion of how we might plan for this becoming distributed memory,<br>
which was impossible before but which I think will be possible by<br>
removing state from the Octs.<br>
<br>
= New Octree Base Class Methods =<br>
<br>
I'd like to propose these methods become part of the base octree class:<br>
<br>
 * next_root(int domain_id, int ind[3])<br>
 * next_child(int domain_id)<br>
<br>
RAMSESOctreeContainer implements the first of these, and a version of<br>
the second of these items.  (Which contains routines that are no<br>
longer necessary.)  The distinction here is that the first of these<br>
routines will be able -- in the future, with no changes to API -- to<br>
add the root level oct to a sparse list of octs that belong to a given<br>
domain; this will, I hope, enable.  Currently it will add them to a<br>
root_mesh attribute that lives on all the octrees.<br>
<br>
By using this, we'll be able to move more of the addition of new octs<br>
into the base Octree class, which should hide all of the logic for<br>
adding new octs from the individual implementations.<br>
<br>
[+-][01] on moving these explicitly to the base class and mandating<br>
their presence?<br>
<br>
Because we're thus going to keep a single method of traversing the<br>
octree, this will also mean that icoords, fcoords and ires can all be<br>
moved to the base class as well, which is the ultimate reason for the<br>
changes to the Octree anyway.<br>
<br>
= Sparse Octrees =<br>
<br>
it is my hope that we can stop allocating the "mask" variable that<br>
gets passed around and is (noct,8) in shape, and instead (if a mask is<br>
needed at all) only look at domain-by-domain information.  For RAMSES<br>
and Gadget this will be a big improvement, but much less so for<br>
NMSU-ART and Tipsy, which are currently not set up for efficient<br>
multi-domain iteration.  This will also mean that spatial chunking<br>
will be more efficient, and I think we'll be able to push mask<br>
selection deeper into the octree object itself.<br>
<br>
However, before we can start looking at distributed octrees with true<br>
sparse oct filling across nodes, we'll need to "pin" the parallelism.<br>
This would mean disabling the ability to add on new communicators, or<br>
possibly splitting workgroups up with an IO handler that communicates<br>
across MPI to the nodes that contain the sparse octree -- if we<br>
instantiate a sparse octree on N processors, we can't then move to<br>
subgroups for instance.  So we'll need a way to pin it.  But, I think<br>
with the changes here to removing global state and using a consistent<br>
mechanism for traversing the octree, we'll be able to do so eventually<br>
in the future.<br>
<br>
-Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div>