Octree dataset don't support generating ghost zones

[yt-fido]

Originally reported by: Kenza Arraki (Bitbucket: karraki, GitHub: karraki)

---

Accessing ('gas', 'density_gradient_x') for ART files fails with AttributeError: 'ARTDomainSubset' object has no attribute 'retrieve_ghost_zones'

script: http://paste.yt-project.org/show/5748/ dataset: D9p_500 http://yt-project.org/data/ error: http://paste.yt-project.org/show/5749/

Version = 3.3-dev Changeset = 60bd0bc6b0a9 (yt) tip

---

• Bitbucket: https://bitbucket.org/yt_analysis/yt/issue/1051

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

Punting to 3.4 since this will require a major new feature for NMSU ART.

[cphyc]

For the record, fixing this issue for oct-AMR datasets would make the following features (it would still require some extra work, but ghost zones is the hard part)

• interactive visualisation
• gradient computation

There is a first draft of that feature in https://github.com/cphyc/yt/tree/ghost_zones_WIP. Here's what needs to be done (this is one possible solution):

1. [x] Find the index of the neighbouring cells of an oct. This function should have a signature oct -> array[4, 4, 4] where the output is the index of the cells. The 2x2x2 at the center of the cube are the cells of the oct, the ones outside are the neighbouring cells.
2. [x] Read in the data for all the cells
3. [x] Return an object that would behave like a classic YTDataChunk but with a shape of noct, 4, 4, 4 instead of noct, 2, 2, 2.

Step 1 is almost done (it needs testing though), but I'm struggling with step 2. Some reasons are

• it is hard to have access to cells that are in another domain
• yt doesn't have a mechanism to access data based on the index (actually I don't understand how yt selects data from a given subset of cells...)

[cphyc]

After #2425 is merged, this will be a low-hanging fruit as one will just have to implement the retrieve_ghost_zones function for the ARTDomainSubset class.

I changed the tags to reflect the fact it should be quite straightforward to do.

[matthewturk]

@cphyc I think this is fixed now, right?

[cphyc]

It is for RAMSES datasets, but some minor work would be required for ART datasets. I don't think I'll have time to do it anytime soon, but if a user requests it at some point it should be very straightforward.

[jzuhone]

@cphyc what would need to be done to fix this for ART datasets?

[cphyc]

One would need to implement the equivalent methods to https://github.com/yt-project/yt/blob/7a8f1b85a23cb6bab1aa4df7b7c9bd3fc8754a5b/yt/frontends/ramses/data_structures.py#L347-L347 and https://github.com/yt-project/yt/blob/7a8f1b85a23cb6bab1aa4df7b7c9bd3fc8754a5b/yt/frontends/ramses/data_structures.py#L443-L443 as well as a mechanism to read data that don't live on leaf cells in ART. I'd be happy to chat more about it!

[jzuhone]

@cphyc ok, we probably should soon. Trying to get an all-hands-on-deck approach to resolving 4.0 issues.

[matthewturk]

Untag from #3125?

[jzuhone]

Yes