[yt-dev] Few questions about YT

Matthew Turk matthewturk at gmail.com
Thu Nov 5 06:28:47 PST 2015


Hi Tomer,

On Tuesday, November 3, 2015, Tomer Nussbaum <tomer.nussbaum at 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
> <https://sketchfab.com/models/d267102434274bdbb5f75f5b9ef27b44>, so with
> some help I might succeed.
>
> Thanx,
> Tomer
>
>
> 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:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20151105/1d70fdb5/attachment.htm>


More information about the yt-dev mailing list