Mailman 3 October 2010 - yt-users

Re: [yt-users] parallelHOP problem, did I break python?
by Stephen Skory 03 Nov '10

03 Nov '10

Geoffrey, > 4. So can someone point me to a 2.0 installation script? > Thanks a bunch. I think the simplest way to get this is to make a new copy of yt in your src/ directory. Do something like this: $ hg clone http://hg.enzotools.org/yt/ yt-2 and then go into yt-2, and copy the 'hdf5.cfg' file from the yt source you have been using in here. Make sure you're using the correct branch "yt": $ hg branch yt And then do: $ python setup.py install You'll have to "make" the fKDpy.so file again, and then do the command above again. Remember, this is the branch that is under active development and has many changes compared to older versions of yt. Some of your scripts may not work without modification. Good luck! Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

3 5

Re: [yt-users] parallelHOP problem, did I break python?
by Stephen Skory 29 Oct '10

29 Oct '10

Geoffrey, > yes I redownloaded Forthon, and did everything under "Fortran kD Tree Setup" > section. Let's take a step back and make sure of a few things 1. I'm guessing you're using yt 2.0? Judging from your pasted error message, I think this will fail: "yt.utilities.kdtree import create_tree" 2. And to make sure why it is failing, is there "fKDpy.so" in your equivalent to this directory? lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/utilities/kdtree 3. Similarly, is there a .so in your equivalent to this? src/yt-hg/yt/utilities/kdtree 4. I just looked at the pHOP code, and there were a couple missing imports that I fixed and just pushed, but I don't think that caused your error. However, it's worth trying again after updating your installation. Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

2 1

yt.extensions.EnzoSimulation gorne
by Elizabeth Tasker 29 Oct '10

29 Oct '10

Hi, Yt is denying the existence of "yt.extensions.EnzoSimulation ": ImportError Traceback (most recent call last) /home/taskere/yt/src/yt-hg/scripts/iyt in <module>() 2 3 from yt.mods import * ----> 4 import yt.extensions.EnzoSimulation as ES 5 6 ETot = [] ImportError: No module named EnzoSimulation Did it change name? I want to iterate through all outputs: es = ES.EnzoSimulation("SedovBlastAMR.enzo", initial_time=0.0, final_time=0.1) for output in es.allOutputs # do barbaric calculations at all output times etc. Thanks, Elizabeth

2 2

Re: [yt-users] parallelHOP problem, did I break python?
by Stephen Skory 29 Oct '10

29 Oct '10

Geoffrey, > name 'fKD' is not defined did you upgrade your yt? You need to build the fKDpy.so file: http://yt.enzotools.org/doc/extensions/running_halofinder.html#fortran-kd-t… Does that fix it? Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

2 3

add_ray problem
by Elizabeth Tasker 28 Oct '10

28 Oct '10

Hi, I've got some (different) problems with add_ray. I have output from the Sedov blast test (so unitless sytems) which is run with a boxsize of 10. I can analyse the results using: ray = pf.h.ray([5., 5., 5.], [10.,10.,10.], "Density") p = pc.add_ray([5.,5.,5.], [10.,10.,10.], "Density") oray = pf.h.ortho_ray(0, [5., 5.], "Density") but only ortho_ray gives the correct result, and it's limited to going along the axes. I've attached the results from the 3 techniques. fig0010.png shows the analytical solution (red line), the ortho_ray solution (green x) and the pf.h.ray solution (blue circles). DD0010_LineQueryPlot shows the results from pc.add_ray. Does anyone know why this isn't behaving? A slice of the shock confirms it looks nice and spherical. Elizabeth

3 5

Particle profiles
by Elizabeth Tasker 26 Oct '10

26 Oct '10

Hi, I'd like to plot dark matter particle density as a function of radius for my particle-only simulation. Can I use add_profile_sphere, but for particles rather than gas? I only have a single halo and I know the halo it's centred in the middle of my box (or it better be, since I put it there!). Is this possible? Thanks, Elizabeth

4 10

yt instinfo should now be fixed
by Matthew Turk 26 Oct '10

26 Oct '10

Hi everyone, It turns out there was a bug in the yt autoupdater, which I believe I have now fixed. You can manually update your yt installation by changing to the yt source directory (which "yt instinfo" will provide correctly) and typing: hg pull hg up python2.6 setup.py develop And now, once again, "yt instinfo -u" will update you to the current tip of whatever branch you are on. Sorry about the bug. -Matt

1 0

hierarchy.io.pop, projection
by david collins 25 Oct '10

25 Oct '10

Hi, Everybody! In order to ensure all my units are being done correctly, I have a field 'TE' that forces 'TotalEnergy' to be read off disk, like this: def _TE(field,data): return data.hierarchy.io.pop(data, 'TotalEnergy') lagos.add_field("TE", function=_TE, validators=[lagos.ValidateGridType()]) This lets me circumvent the assumptions that yt makes on a field by that name, specifically unit conversion. However, I can't seem to project it. I get the error, below. Does anyone have any ideas of either different ways to do this, or ways around the projection error? Thanks, d. Traceback (most recent call last): File "<stdin>", line 1, in <module> File "tmp.py", line 9, in <module> mp.plot() File "/home/dccollin/yt/uber.py", line 398, in plot fig = self.add_plots(field,axis,FirstOne) File "/home/dccollin/yt/uber.py", line 676, in add_plots **extra_args) File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/raven/plot_collection.py", line 719, in add_projection **field_parameters) File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/BaseDataTypes.py", line 1205, in __init__ self._refresh_data() File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/BaseDataTypes.py", line 237, in _refresh_data self.get_data() File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/BaseDataTypes.py", line 1380, in get_data self._get_dependencies(fields), self.hierarchy.io) File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/ParallelTools.py", line 1438, in _get_dependencies deps += ensure_list(fi[field].get_dependencies(pf=self.pf).requested) File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/field_info_container.py", line 297, in get_dependencies self(e) File "/projects/lca-group/local-dev/lib/python2.6/site-packages/yt-2.0dev-py2.6-linux-x86_64.egg/yt/lagos/field_info_container.py", line 318, in __call__ dd = self._function(self, data) File "xtra_fields.py", line 161, in _TE dataset = data.hierarchy.io.pop(data, 'TotalEnergy') AttributeError: 'fake_io' object has no attribute 'pop' -- Sent from my Stone Tablet and carried by my Pterodactyl.

3 2

anti-aliasing slices with near-constant fields
by Nathan Roth 25 Oct '10

25 Oct '10

Hello, Could I see an example of the lines of code that would allow me to view a slice with anti-aliasing turned off? In a test problem I am running, some fields values start out with constant values across the simulation box, and when I plot slices they show up garbled. Thanks, Nathan

2 1

ghost zones and non-periodic boundary conditions
by j s oishi 24 Oct '10

24 Oct '10

Hi all, I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones: pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity') However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely, gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2] and gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2] This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction. Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug? I realize this is not a very clear question, but I'm a bit confused myself. thanks, j

5 6