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.
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.
I'm using a code which creates a new field by assigning values to
If --in the middle of the script-- I create a projected image, the new
field gets wiped.
This script demonstrates the problem:
Here, the code loops over two objects, and gives their neighbouring
cells values in the new field and creates an extracted region from
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
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!)
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, 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>
>> 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>
>>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman(a)gmail.com>
>>> > 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
>>> > volume should stay, especially since I think it will soon be possible
>>> > do
>>> > an off_axis_projection of a data object which would probably be fed
>>> > through the volume.
>>> Why not get rid of volume and instead supply data_source, like
>>> > 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
>>> >> routine off_axis_projection. Cameron and Sam, do you think it would
>>> >> be okay if we sim
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
More elegant solutions are welcome, but this worked for me.
Traceback (most recent call last):
File "./test_runner.py", line 29, in <module>
from yt.utilities.answer_testing.api import \
line 26, in <module>
line 26, in <module>
line 133, in <module>
from matplotlib.rcsetup import (defaultParams,
line 19, in <module>
from matplotlib.colors import is_color_like
line 52, in <module>
import numpy as np
line 137, in <module>
line 9, in <module>
from numpy.lib import add_newdoc
line 4, in <module>
from type_check import *
line 8, in <module>
import numpy.core.numeric as _nx
line 5, in <module>
2): no suitable image found. Did find:
mach-o, but wrong architecture
Sent from my computer.
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