Hi all,
Good news on the Windows/yt front. I'm happy to announce that as of
right now only one unit test is failing. The failure is subtle, but I
thought I would run it by you all to see what we should do about it.
The failure in question is a comparison test in
yt/utilities/tests/test_units.py, in "test_power":
assert u2.cgs_value == (pc_cgs**2 * mK_cgs**4)**2
basically, the unit cgs_value is exactly the combination of these
factors, so even though they are floats, one would expect that the
equality should hold, and on our other platforms it does. However, on
Windows, the comparison is failing on the last digit, with a relative
difference of ~4e-16 between the two values. So, while I'm not
inclined to be very concerned about it, I'm curious to see what you
guys think about how it should be handled.
Happy New Year!
John Z
--
John ZuHone
Postdoctoral Researcher
NASA/Goddard Space Flight Center
jzuhone(a)gmail.com
john.zuhone(a)nasa.gov
Hi all,
There was some discussion in IRC of how to test out the new unit
refactor branch. Not all of the frontends have been converted.
Here's how to pull it:
hg pull -r unitrefactor http://bitbucket.org/MatthewTurk/yt
hg up -r unitrefactor
Then, build as usual. As a reminder, this is the primary yt repository now:
http://bitbucket.org/yt_analysis/yt
If you have that set as your "default", you can get back to the tip of
that repository like so:
hg up -r "remote(tip)"
If you want to make sure you're updating to a specific branch, swap
out "tip" for "yt" or "yt-3.0" (which will need to be in quotes, as -
is a special character in revsets.
-Matt
Hi everyone,
I’ve been trying to run Enzo with inline yt lately and have encountered a strange error when using yt-3.0. yt is able to load the pf from Enzo, but doing much more than that results in the error
AttributeError: 'IOHandlerInMemory' object has no attribute '_read_fluid_selection'
(full output and traceback: http://pastebin.com/TY9EVDWd)
After this Enzo resumes running, but yt will always fail in the same way.
This same error arises when doing anything simple like making slices or projections, halo finding, making profiles, etc. Curiously, this doesn’t happen build and run Enzo with either the stable or dev branches of yt, and yt-3.0 works just fine when running on its own, either interactively or from a simple script independent of Enzo. The same behavior occurs both locally running OSX 10.9 and running on a Linux machine. Has anyone encountered this before, or have a clue to point me in the right direction to sort it out?
Thanks,
Brian
Hi all,
Because I enjoy weeping and gnashing of teeth, I've spent some time off and on over the last few weeks attempting to get yt working on Windows. This turned out to be easier than I had anticipated using conda, but still kind of miserable.
In any case, we have something that does work on Windows, but on x86 only at the moment. This is because something is screwy with the way Anaconda builds HDF5 and h5py on Windows (both x86 and x86_64), and I had to use the binary version of h5py compiled for Windows to get it to work. The latter is only 32-bit.
I've been able to do some basic operations on objects, and make some PlotWindow plots. What I know doesn't work so far:
1) I couldn't get png_writer to compile, and as I recall we are probably going to dump this soon(?), so it's currently not built.
2) Halo finding doesn't work because the modules depend on some header file that Windows doesn't have. We might be able to make this work at some point, though.
3) Reason
If you have a Windows x86 box sitting around and you're curious, please play around with it. Here's how to get it working:
1) Get the Windows x86 version of miniconda here: http://repo.continuum.io/miniconda/Miniconda-2.2.3-Windows-x86.exe
2) Once you've installed it, download the binary version of h5py for 32-bit Windows and Python 2.7 here: https://code.google.com/p/h5py/downloads/list
When you install this, you have the option of pointing it to the Python distribution that Miniconda installed.
3) From the command prompt, install yt by issuing:
conda install yt -c http://conda.binstar.org/jzuhone
which should pick up the rest of the necessary packages, but you should also use conda to install IPython, Mercurial, and the like.
4) If you want to develop, fork my fork:
http://bitbucket.org/jzuhone/yt-windows
the command to develop with a yt source directory is slightly different, it has to be:
python setup.py build --compiler=mingw32 develop
also issue this from the command line before you build:
set PNG_DIR = c:\{path to your miniconda directory}\Library
The only "box" I have at the moment is a virtual machine on my laptop that isn't exactly a good testing platform, so if someone has a box somewhere where they'd like to set up testing that'd be great. I'm also going to see if there's something here at Goddard I can log into to use.
Once we're satisfied that most things aren't breaking too badly I'll issue a PR from my fork.
Best, Merry Christmas, and Happy Holidays,
John Z
New issue 756: annotate_grids callback broken in yt-3.0
https://bitbucket.org/yt_analysis/yt/issue/756/annotate_grids-callback-br...
Cameron Hummels:
yt fails when I try to run the annotate_grids callback on a SlicePlot (or ProjectionPlot).
I'm on unitrefactor tip (changeset: d20587c1602e), but this occurs on yt-3.0 tip too (changeset: 78664aafcfec):
I run this script:
http://paste.yt-project.org/show/4164/
on a 2D enzo dataset, and get this callback:
http://paste.yt-project.org/show/d4aYqgLDmRb2CNtR2RsU
As far as I can tell, the problem lies in the fact that YTSlice doesn't inherit the attributes from the YTSelectionContainer (and GridPropertiesMixin object) as it did in 2.x when the Slice was done through an AMR2DData object which was a subclass of GridPropertiesMixin. GridPropertiesMixin set grid_left_edge as an attribute, which no longer exists in 3.0.
New issue 755: YTArray is not pickleable
https://bitbucket.org/yt_analysis/yt/issue/755/ytarray-is-not-pickleable
Nathan Goldbaum:
After applying the following diff:
```
#!diff
diff -r d20587c1602e yt/data_objects/yt_array.py
--- a/yt/data_objects/yt_array.py Tue Dec 17 14:35:41 2013 -0500
+++ b/yt/data_objects/yt_array.py Wed Dec 18 14:18:00 2013 -0800
@@ -261,7 +261,7 @@
"""
"""
- if obj is None:
+ if obj is None and hasattr(self, 'units'):
return
self.units = getattr(obj, 'units', None)
```
You can try the following test script which illustrates the problem:
```
#!python
○ cat test_pickle.py
from yt.data_objects.yt_array import YTArray as array
import cPickle as pickle
arr = array([1,2,3], 'g')
with open('save.p', 'wb') as f:
pickle.dump(arr, f)
with open('save.p', 'rb') as f:
data_read = pickle.load(f)
print arr
print data_read
```
On my machine, this prints:
```
[1 2 3] g
[1 2 3] None
```
This is related to #754 and #743.
New issue 754: Bug when creating timeseries in parallel but not serial in unit refactor
https://bitbucket.org/yt_analysis/yt/issue/754/bug-when-creating-timeseri...
Cameron Hummels:
When I run the following script to create a time series (using the simulation object), it runs fine with a single processor, but it fails when running with multiple processors. This works fine in yt 2.x, and it appears to be due to a units comparison in the unit refactor.
Script:
http://paste.yt-project.org/show/4162/
Success when called:
$ mpirun -np 1 python script.py --parallel
Failure when called:
$ mpirun -np 2 python script.py --parallel
The traceback:
http://paste.yt-project.org/show/R9q0swQ0E7z1hbgHyTJl/
I did end up finding a way around this, so it isn't a dire need to have this working, but I thought it might be indicative of some larger problem in the code.
My solution script:
http://paste.yt-project.org/show/4163/
New issue 753: SlicePlot differences from 2.x to 3.0
https://bitbucket.org/yt_analysis/yt/issue/753/sliceplot-differences-from...
Cameron Hummels:
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.
New issue 752: Segmentation fault during isocontour extraction
https://bitbucket.org/yt_analysis/yt/issue/752/segmentation-fault-during-...
Nathan Goldbaum:
I just tried running the following test script:
```
#!python
from yt.mods import *
pf = load('DD0000/DD0000')
dd = pf.h.disk('c', [0,0,1], (20, 'kpc'), (3, 'kpc'))
iso = dd.extract_isocontours('Radiuskpc', 10)
```
I got the following output:
```
[goldbaum@hyades low_resolution_static_subgrids]$ python test.py
yt : [INFO ] 2013-12-13 11:48:07,582 Parameters: current_time = 0
yt : [INFO ] 2013-12-13 11:48:07,582 Parameters: domain_dimensions = [64 64 64]
yt : [INFO ] 2013-12-13 11:48:07,583 Parameters: domain_left_edge = [ 0. 0. 0.]
yt : [INFO ] 2013-12-13 11:48:07,584 Parameters: domain_right_edge = [ 1. 1. 1.]
yt : [INFO ] 2013-12-13 11:48:07,584 Parameters: cosmological_simulation = 0.0
Parsing Hierarchy 100% |||||||||||||||||||||||||||||||||||||||||||| Time: 0:00:00
yt : [INFO ] 2013-12-13 11:48:07,592 Gathering a field list (this may take a moment.)
Extracting 37% |------------------ | ETA: 0:00:00
Segmentation fault
```
I can upload the data somewhere if that would be helpful. This is on the tip of the stable branch.
