search

yt-project / yt

Main yt repository
http://yt-project.org
Other
461 stars 276 forks source link

SlicePlot differences from 2.x to 3.0 #753

Closed yt-fido closed 7 years ago

yt-fido commented 10 years ago

Originally reported by: chummels (Bitbucket: chummels, GitHub: chummels)

I have a small 2D dataset from an enzo KH test (64^2 dataset): http://www.astro.columbia.edu/~chummels/DD0010.tar

I take a SlicePlot of it using this simple script: http://paste.yt-project.org/show/4157/

When I do this in yt 2.6 dev (changeset 6bffc737a67a), I get this image: http://i.imgur.com/nfGs13M.png

When I do this in yt 3.0 vanilla (changeset: 7026b9ddfc20), I get this image: http://i.imgur.com/va2c9TF.png

When I do this in yt 3.0 unitrefactor (changeset: a26e91190d0e), I get this image: http://i.imgur.com/SfRb5AW.png

The most obvious change is that the axes are flipped between the 2.x and 3.0 renderings. The 2.x renderings are correct in that the stratification of the fluids should be in the y direction, not the x direction.

The second obvious change is in units. Note again, the 2.x units are correct in that this is a 1x1 area in code units, which it displays as having axes length 1cmx1cm. The vanilla 3.0 units are the same as the 2.x units. The 3.0 unitsrefactor axis length units are seemingly scaled by some constant that applies in cosmological runs, because instead of being 1cm x 1cm, they are now ~7e10 x 7e10 solar radii in size.

Perhaps this is just a change for 2D datasets, but I figure it is worth looking into for everything.

yt-fido commented 9 years ago

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

Removing milestone: 3.0 (automated comment)

yt-fido commented 10 years ago

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

Fixed by cameron.

yt-fido commented 10 years ago

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

I just checked and slices of IsolatedGalaxy appear identical in 2.X and 3.0, so I think this is an issue with the way 2D data is displayed or read in, as @MatthewTurk suspected.

yt-fido commented 10 years ago

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

I think these are separate bugs. I believe, but am not certain, that the issue with the slice plot in 3.0 is data access. I don't believe that 3D datasets encounter this. To try to fix that issue, this changing this line in yt/frontends/enzo/io.py :

ds = np.atleast_3d(gds.get(fname).value)

to

ds = np.atleast_3d(gds.get(fname).value.transpose())

and seeing if that fixes it. If you have any with refinement (this looks like it's static) this would show up differently, I believe, and look very broken.

For the units issue, it's probably just an issue with how unit systems are detected. If you look in the definition of set_code_units in yt/frontends/enzo/data_structures.py you can see where it makes various decisions about units. One of these is likely incorrect. Another helpful diagnostic would be:

print pf.domain_width.in_units('code_length'), pf.domain_width.in_units('cm'), pf.domain_width.in_units('Mpc')