Hi Jean,<br><br>Cool!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
astro-physics code. First question: Can we set a threshold to switch the<br>
GeometryFilter to a bounding box mode when loading an hyperoctree? By<br>
default the surface-mode is always ON and for an octree beyond 8 levels<br>
of refinement, things are getting heavy.<br></blockquote><div><br>Yes. If you send me a patch, I'll commit it right away.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Second question: I don't see what method should be used for<br>
parallelizing the construction of the octree. Could one use tags such a<br>
mixture of UPDATE_RESOLUTION and UPDATE_PIECE_NUMBER to divide up the<br>
load? Are filters downstream ready to propagate the meta-data requests<br>
for octrees? The example of the HyperOctree Fractal does a depth-first<br>
construction. I suppose breadth-first is also possible since the<br>
HyperOctreeCursor enables navigation in both direction. Simulation codes<br>
actually use space-filling curves (e.g. Hilbert curves or others) and in<br>
terms of reading back the data, this could one efficient way to access<br>
data from disk, where each server follows a segment of the Hilbert<br>
curve. I just don't know if anyone has ever done parallel octree builds<br>
in ParaView and if this is feasible?<br></blockquote><div><br>I forwarded this to Charles and Brad who originally developed the octree functionality.<br><br>Can we chat sometime in the near future about this?<br><br>-berk <br>
</div></div>