Mailman 3 July 2012 - yt-dev

Switching data/hub today
by Matthew Turk 06 Jul '12

06 Jul '12

Hi all, I'm switching the data.yt-project.org domain to be just hub.yt-project.org. It's still not at 100%, but I want the existing projects to be visible. Should be up and visible by this afternoon. -Matt

2 2

workshop on building community codes for effective scientific research on HPC platforms
by Brian O'Shea 05 Jul '12

05 Jul '12

See the attached announcement. Postdocs and grad students are particularly encouraged to apply. As far as I know there isn't a website yet - email Anshu Dubey (dubey(a)flash.uchicago.edu) if you're interested. --Brian

1 0

Projection wipes grids
by Elizabeth Tasker 04 Jul '12

04 Jul '12

Hi, I'm using a code which creates a new field by assigning values to individual cells. If --in the middle of the script-- I create a projected image, the new field gets wiped. This script demonstrates the problem: http://paste.yt-project.org/show/2517/ Here, the code loops over two objects, and gives their neighbouring cells values in the new field and creates an extracted region from those cells. When the second object is called, the code reassigns its cells to object one and creates a new extracted region of object one's cells. If line 53 is not called (p = pc.add_projection("Density", 2)), this is fine. Both objects initially have 26 cells and then object one gets 52 cells. If the projection is created, the code forgets about the cells it assigned to object 1 in the first loop and object 1 ends up with only object 2's cells. This isn't a huge problem for me, since I can just ensure I never call a projection during my script. But.... I am liable to forget and clobber my data at a later point! Is it easy to somehow bank the new field so it's not destroyed during a projection? (If not, no worries.) (Matt, I know we previously discussed how projection didn't know about the new field. Possibly, this is a logical consequence from that and if so, I'm sorry to repeat the question!) Elizabeth

2 2

Re: [yt-dev] off_axis_projection
by Cameron Hummels 03 Jul '12

03 Jul '12

Hey guys, I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU. Cameron > Okay. > > Cameron, I know you rely upon the off_axis_projection -- would it be > okay, in your opinion, if we deprecated the interpolated = True option > in some 2.X release and then in 3.0, if you want interpolation, you > need to set up a projection camera yourself? I ask because the setup > for these two is very different, and (in the spirit of the plot > window!) I'd like to try to reduce the complexity. If you're -1 on > this, then we can keep it the way it is. > > On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman(a)gmail.com> > wrote: >> That capability doesn't exist yet for interpolated=True. When that is >> possible, I would be +1 with moving from volume to data_source. >> >> >> On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk(a)gmail.com> >> wrote: >>> >>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman(a)gmail.com> >>> wrote: >>> > Hi all, >>> > >>> > I think the only kwarg I'd be really +1 with getting rid of would be >>> > no_ghost. interpolated=True should just trigger no_ghost=False, and >>> > interpolated=False doesn't use the ghost zones no matter what. I >>> think >>> > volume should stay, especially since I think it will soon be possible >>> to >>> > do >>> > an off_axis_projection of a data object which would probably be fed >>> in >>> > through the volume. >>> >>> Why not get rid of volume and instead supply data_source, like >>> projections? >>> >>> > >>> > Sam >>> > >>> > >>> > On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk(a)gmail.com> >>> > wrote: >>> >> >>> >> Hi Elizabeth, >>> >> >>> >> I agree, this makes sense. >>> >> >>> >> Last night I tried to take a crack at this, but I got very confused >>> >> with the various definitions of volume, interpolated, etc etc, in >>> the >>> >> routine off_axis_projection. Cameron and Sam, do you think it would >>> >> be okay if we sim

4 9

Odd compile, OSX10.6, OMP, x86 vs. i386
by david collins 03 Jul '12

03 Jul '12

Hi, all-- Sam and I tracked down an odd glitch. It started with trying to run the test runner, and I got an error on the "from yt.utilities.answer_testing.api import" (full trace below) For some reason the build of yt/utilities/lib/grid_traversal.pyx was looking for $DEST_DIR/lib64 and not finding it, trying to use /usr/local/lib/libgomp.dylib which, for some reason is built for i386 rather than x86_64. Putting /usr/local/lib/x86_64 in LD_LIBRARY_PATH didn't seem to work, but soft linking /usr/local/lib/x86_64 to $DEST_DIR/lib64 worked. More elegant solutions are welcome, but this worked for me. d. /run>./test_runner.py --quicksuite=True --output-dir=/Users/dccollins/ThisScratch/TestRunnerFiducial Traceback (most recent call last): File "./test_runner.py", line 29, in <module> from yt.utilities.answer_testing.api import \ File "/Users/dccollins/local2/src/yt-hg/yt/utilities/answer_testing/__init__.py", line 26, in <module> import runner File "/Users/dccollins/local2/src/yt-hg/yt/utilities/answer_testing/runner.py", line 26, in <module> import matplotlib File "/Users/dccollins/local2/lib/python2.7/site-packages/matplotlib/__init__.py", line 133, in <module> from matplotlib.rcsetup import (defaultParams, File "/Users/dccollins/local2/lib/python2.7/site-packages/matplotlib/rcsetup.py", line 19, in <module> from matplotlib.colors import is_color_like File "/Users/dccollins/local2/lib/python2.7/site-packages/matplotlib/colors.py", line 52, in <module> import numpy as np File "/Users/dccollins/local2/lib/python2.7/site-packages/numpy/__init__.py", line 137, in <module> import add_newdocs File "/Users/dccollins/local2/lib/python2.7/site-packages/numpy/add_newdocs.py", line 9, in <module> from numpy.lib import add_newdoc File "/Users/dccollins/local2/lib/python2.7/site-packages/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/Users/dccollins/local2/lib/python2.7/site-packages/numpy/lib/type_check.py", line 8, in <module> import numpy.core.numeric as _nx File "/Users/dccollins/local2/lib/python2.7/site-packages/numpy/core/__init__.py", line 5, in <module> import multiarray ImportError: dlopen(/Users/dccollins/local2/lib/python2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image found. Did find: /Users/dccollins/local2/lib/python2.7/site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture -- Sent from my computer.

2 2

possible Forthon 0.8.8 and 0.8.9 issues?
by Geoffrey So 01 Jul '12

01 Jul '12

Has anyone installed yt-dev from scratch recently and used the newer than 0.8.7 Forthon(s)? I was able to use make to compile the 8.8 and 8.9 after removing the --with-numpy argument from the Makefile inside the yt/utilities/kdtree, however, I get fKD' is not defined when I use functions that requires the kd-tree. I was able to bypass this problem by reinstalling YT and then using Forthon 0.8.7 (removing Forthon 8.8/8.9 then installing 8.7 then reinstallling YT did not work). I was wondering if anyone else ran into the same issue? Not urgent because 8.7 works. From G.S.

2 1