Trouble plotting a simple ramses dataset

[yt-fido]

Originally reported by: Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum)

---

Using the following script:

#!python

from yt.mods import *
pf = load('/pfs/hennebel/KH/output_00037/info_00037.txt')
slc = SlicePlot(pf, 'z', 'Density')

I get the following traceback:

#!python traceback

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    slc = SlicePlot(pf, 'z', 'Density')
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/visualization/plot_window.py", line 1254, in __init__
    slc = pf.h.slice(axis, center[axis],
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/data_objects/static_output.py", line 218, in hierarchy
    self, data_style=self.data_style)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 303, in __init__
    super(RAMSESGeometryHandler, self).__init__(pf, data_style)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/geometry/geometry_handler.py", line 68, in __init__
    self._setup_geometry()
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/geometry/oct_geometry_handler.py", line 50, in _setup_geometry
    self._initialize_oct_handler()
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 308, in _initialize_oct_handler
    for i in range(self.parameter_file['ncpu'])]
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 72, in __init__
    self._read_amr()
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 250, in _read_amr
    assert(n == ng)
AssertionError

The dataset is a simple 3D kelvin helmholtz test. I've uploaded a copy to my website (warning, 5GB): http://ucolick.org/~goldbaum/files/kh.tar

I don't know much about this dataset as I got it precanned from Patrick Hennebelle so sorry if I can't provide much detail. FWIW, this is on the current tip of 3.0 (250ee66bf017).

---

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

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

This was fixed.

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

@nickolas1 FWIW, I think I saw a way around it and I issued a pull request to check out. Let me know if it works.

[yt-fido]

Original comment by nickolas1 (Bitbucket: nickolas1, GitHub: nickolas1):

---

sure, I'll check this out.

(using 3.0, btw. The datasets I'm looking at are kind of huge, but if necessary I can make some small ones demonstrating the problem)

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

@nickolas1 looking over the code, there are a few loops:

for cpu in range(self.amr_header['nboundary'] + self.amr_header['ncpu']):

I think actually that as you described, the specified boundary conditions may be causing an issue. What will happen is that the octree won't add them (as they are outside the domain) and then the number added won't be the right number.

Can you check to see, when it fails, if the variable cpu is inside the nboundary value, and if so, what the values of pos are? Are they inside the domain or outside?

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

Any chance you can share the dataset? My guess is that there's something wrong with how it's counting grids. Which version are you on, by the way?

[yt-fido]

Original comment by nickolas1 (Bitbucket: nickolas1, GitHub: nickolas1):

---

No, they're all 3d, and I'm always specifying which fields are present.

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

@nickolas1 by any chance, is the dataset either 2D, or having a non-standard set of fields? The fields yt assumes (currently) are ["Density", "x-velocity", "y-velocity", "z-velocity", "Pressure", "Metallicity"].

[yt-fido]

Original comment by nickolas1 (Bitbucket: nickolas1, GitHub: nickolas1):

---

Nathan, were you ever able to plot the KH dataset? If not, do you know if the boundary conditions for this run were specified in the namelist? I guess if it's a KH test it must have had inflow/outflow specified along one axis.

The reason I ask is that I'm running into this same assert(n==ng) error with any dataset that has specified boundary conditions rather than using the default periodic box.

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

Yup, I will do so. Following that let's close this issue and I will open a new one for 2D datasets.

[yt-fido]

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

---

Is there some way to detect that the data is reduced dimensionality? It would be nice to raise a NotImplimentedError in RAMSESStaticOutput when someone tries to load such a dataset.

[yt-fido]

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

---

I believe that 2D datasets are not currently supported in 3.0. To fix this we will need to generalize the Octrees somewhat (so that they can either function as quadtrees or have variable refinement in each direction) which may be a bigger task than I can take on just now.

[yt-fido]

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

---

I was able to load and visualize the 3D Sedov blast test by explicitly specifying the field names:

#!python

from yt.mods import *
pf = load('/pfs/hennebel/SEDOV3D/output_00009/info_00009.txt',
          fields = ["Density", "x-velocity", "y-velocity",
                    "z-velocity", "Pressure"])
slc = SlicePlot(pf, 'z', 'Density')
slc.save()

Image is here: http://i.imgur.com/1WFSWu5.png

Specifying field names doesn't seem to help with the 2D datasets or the Kelvin Helmholtz dataset.

[yt-fido]

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

---

I get a different traceback for a 3D sedov-taylor problem:

#!python traceback

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    slc = SlicePlot(pf, 'z', 'Density')
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/visualization/plot_window.py", line 1256, in __init__
    slc.get_data(fields)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/data_objects/data_containers.py", line 520, in get_data
    fluids, self, self._current_chunk)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/geometry/geometry_handler.py", line 479, in _read_fluid_fields
    chunk_size)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/io.py", line 51, in _read_fluid_selection
    rv = subset.fill(content, fields, selector)
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 275, in fill
    for level, offset in enumerate(self.domain.hydro_offset):
  File "/home/goldbaum/yt-x86_64/src/yt-3.0/yt/frontends/ramses/data_structures.py", line 113, in hydro_offset
    assert(hvals['file_ilevel'] == level+1)
AssertionError

I've uploaded this dataset to my website as well (1.3 GB): http://ucolick.org/~goldbaum/files/sedov_3d.tar

[yt-fido]

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

---

I'm getting the same traceback on some 2D datasets so perhaps the problem is that 2D support isn't quite there yet.