Hi Tomer,

On Tuesday, November 3, 2015, Tomer Nussbaum <tomer.nussbaum@mail.huji.ac.il> wrote:

Hey guys,

I continue to work on the 3D thing, and I have a few questions, it would be super helpful if you can answer me, even for some of my questions. So if you even have a hint I would like to hear about it.

Thats what I have now: ART example, so with some help I might succeed.


0. What is the main reason that _extract_isocontours_from_grid doesn't work on ART?
is it just not implemented? is there another big problem beneath it? is it related to KDTree?
How come ENZO work and ART doesn't?

So here's the big issue, which underlies the rest: the only indexing scheme that has ghost zones implemented is the patch grid frontend.  So it will work with Enzo, FLASH, Athena, ..., but ART uses octrees, for which we haven't implemented.

1. What is the ghost zones idea? does it work on ENZO? does it work on ART OcTree data?

The reason we use ghost zones (which can be avoided by specifying use_ghost=False) is to avoid extrapolating at the edges.  The isocontour extraction needs to take place within vertex data.  The way the marching cubes algorithm works is to look at the relative values of the eight corners of a cube, then determine how to insert one or more surfaces to create an isocontour.

By using ghost zones, we can get a considerably higher-order vertex centering of the data.  Without them, the isocontours are usually cracky and broken.
2. Can ghost_zone_interpolate work on OcTree? on OctreeSubsetBlockSlice? 

In principle, yes.  But it will require work.  What will be needed is a mechanism for taking an OctreeSubset object (in ART there may be only *one* of these, which will ease the process considerably) and then filling in an additional layer of cells inside each oct during the filling process.  To do this, something like the following would need to occur:

 * Create a new grid_visitors function that accepts the neighbors to a given oct as well as the oct itself
 * Compute the neighbors in advance, filling in an array with their indices, with the .neighbors operation
 * Examine those neighbors, filling them in, and return that.

The problem with this is that it touches a lot of relatively tedious code that has a low bus factor.  And right now I can't dedicate the time to doing it, although it is important and I would like to.
3. In get_vertex_centered_data, it gets from ENZO  6X6X6 data blocks, is it true that one of the differences between ENZO and ART,
is that the adaptive mesh of Art is divided to 2X2X2 but ENZO has 6X6X6?

Enzo will have variable sizes.  In general, the main difference from yt's perspective between Oct and Patch data is that Oct data is handled as a set of octs, and patch data is handled on each patch individuals.
The code I look at is in "construction_data_containers.py" YTSurfaceBase.get_data(..) function
line 1031: for block, mask in self.data_source.blocks:

4. What is main idea of the classes AMRGridPatch(YTSelectionContainer), OctreeSubsetBlockSlice(object), 
OctreeSubset(YTSelectionContainer)? what is the difference between them?
doesn't OctreeSubsetBlockSlice supposed to inherite OctreeSubset?

The OctreeSubsetBlockSlice is a means of making Octs look a bit like Patches ... and it's slow to use it.
while calling self.data_source.blocks for ENZO I get AMRGridPatch and for ART I get OctreeSubsetBlockSlice.
but AMRGridPatch inherits from YTSelectionContainer as OctreeSubset. different to OctreeSubsetBlockSlice which inherits from object...

The code I look at is in "construction_data_containers.py" YTSurfaceBase.get_data(..) function
line 1031: for block, mask in self.data_source.blocks: