Mailman 3 August 2011 - yt-users

Stars on volume rendering
by Elizabeth Harper-Clark 11 Dec '21

11 Dec '21

Hi all, Thanks for all your help over the last couple of days. One more question: - Can I plot particles on a volume rendered image? I have stars and I want to show where they are! Thanks, Libby -- Elizabeth Harper-Clark MA MSci PhD Candidate, Canadian Institute for Theoretical Astrophysics, UofT Sciences and Engineering Coordinator, Teaching Assistants' Training Program, UofT www.astro.utoronto.ca/~h-clark <http://www.astro.utoronto.ca/%7Eh-clark> h-clark(a)cita.utoronto.ca Astronomy office phone: +1-416-978-5759

8 14

Clear memory?
by Elizabeth Tasker 01 Sep '11

01 Sep '11

Hi, Is there any way in yt to get a script to delete (or ignore) all the .yt and .harray files and clear its memory? I run into errors when I'm re-doing a plot or I've re-run the simulation and over-written the last data set I looked at with yt. I have to exit yt, delete the above files by hand and restart, which is a bit of a pain. Elizabeth

4 8

Issue with hierarchy stats
by Jean-Claude Passy 29 Aug '11

29 Aug '11

Hi all, I am running a modified TestOrbit problem. If I try to look at the hierarchy of the first dump, everything is working just fine: --------------------------------------------------------------------------------------------------------------------- In [32]: filen1 = 'DD0000/data0000' In [33]: pf1 = load(filen1) yt : [INFO ] 2011-08-29 13:26:58,698 Parameters: current_time = 0 yt : [INFO ] 2011-08-29 13:26:58,698 Parameters: domain_dimensions = [32 32 32] yt : [INFO ] 2011-08-29 13:26:58,698 Parameters: domain_left_edge = [0 0 0] yt : [INFO ] 2011-08-29 13:26:58,698 Parameters: domain_right_edge = [1 1 1] yt : [INFO ] 2011-08-29 13:26:58,698 Parameters: cosmological_simulation = 0.0 In [34]: pf1.h.print_stats() level # grids # cells --------------------------- 0 1 32768 ---------------------------- 1 32768 t = 0.00000000e+00 = 0.00000000e+00 s = 0.00000000e+00 years Smallest Cell: Width: 1.013e-26 mpc blablabla.... --------------------------------------------------------------------------------------------------------------------- However, if I try to do the same for a later dump: --------------------------------------------------------------------------------------------------------------------- In [40]: filen1 = 'DD0001/data0001' In [41]: pf1 = load(filen1) yt : [INFO ] 2011-08-29 13:29:56,004 Parameters: current_time = 0.0001000089999 yt : [INFO ] 2011-08-29 13:29:56,004 Parameters: domain_dimensions = [32 32 32] yt : [INFO ] 2011-08-29 13:29:56,004 Parameters: domain_left_edge = [0 0 0] yt : [INFO ] 2011-08-29 13:29:56,004 Parameters: domain_right_edge = [1 1 1] yt : [INFO ] 2011-08-29 13:29:56,004 Parameters: cosmological_simulation = 0.0 In [42]: pf1.h.print_stats() --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /rpod2/jcpassy/yt-x86_64/src/yt-hg/scripts/iyt in <module>() ----> 1 2 3 4 5 /rpod2/jcpassy/yt-x86_64/src/yt-hg/yt/data_objects/static_output.py in hierarchy(self) 167 raise RuntimeError("You should not instantiate StaticOutput.") 168 self._instantiated_hierarchy = self._hierarchy_class( --> 169 self, data_style=self.data_style) 170 return self._instantiated_hierarchy 171 h = hierarchy # alias /rpod2/jcpassy/yt-x86_64/src/yt-hg/yt/frontends/enzo/data_structures.py in __init__(self, pf, data_style) 160 self.float_type = 'float64' 161 --> 162 AMRHierarchy.__init__(self, pf, data_style) 163 # sync it back 164 self.parameter_file.data_style = self.data_style /rpod2/jcpassy/yt-x86_64/src/yt-hg/yt/data_objects/hierarchy.py in __init__(self, pf, data_style) 58 59 mylog.debug("Counting grids.") ---> 60 self._count_grids() 61 62 # Must be defined in subclass /rpod2/jcpassy/yt-x86_64/src/yt-hg/yt/frontends/enzo/data_structures.py in _count_grids(self) 182 self.num_grids = test_grid_id = int(line.split("=")[-1]) 183 break --> 184 self._guess_data_style(self.pf.dimensionality, test_grid, test_grid_id) 185 186 def _guess_data_style(self, rank, test_grid, test_grid_id): /rpod2/jcpassy/yt-x86_64/src/yt-hg/yt/frontends/enzo/data_structures.py in _guess_data_style(self, rank, test_grid, test_grid_id) 185 186 def _guess_data_style(self, rank, test_grid, test_grid_id): --> 187 if test_grid[0] != os.path.sep: 188 test_grid = os.path.join(self.directory, test_grid) 189 if not os.path.exists(test_grid): TypeError: 'NoneType' object is not subscriptable --------------------------------------------------------------------------------------------------------------------- Could someone help me to fix this ? Thanks a lot, JC

2 2

readline recognition issue
by Elizabeth Tasker 29 Aug '11

29 Aug '11

Hi I've installed yt on a new linux system and iyt is unable to find readline. When I start it says: [taskere@purr ~]$ ~/yt/bin/iyt WARNING: Readline services not available on this platform. But readline is on this machine and works fine from the normal bash prompt. Any ideas? Elizabeth

3 5

Trajectories
by John ZuHone 28 Aug '11

28 Aug '11

Hi all, Has anyone ever used yt to construct particle trajectories? I have something I have coded up myself to do this but it is rather slow. For each timestamp, it looks for the particles by index, sorts them in order, and then appends the particle properties to each trajectory. It could be that although I'm using numpy for all of the array manipulations, that I'm still doing all of this in python, and doing this in cython would probably be faster. Best, John ZuHone

2 1

Making grid fields from particles
by Eric Hallman 27 Aug '11

27 Aug '11

Hello all, I looked through the previous threads on yt-users, and I don't see this particular problem described. Hoping for some help. So, the quantity dark_matter_density is a CIC-deposited particle quantity, which becomes a grid field. I would like to do something like this: for every grid voxel, calculate the mean dm particle *velocity* inside that voxel return as a grid field Is that simple using CIC_deposit? The only mean particle velocity I've seen used in yt/enzo before is the one calculated for halos, by using HOP or FOF identification. thanks! Eric

3 2

Service interruption
by Matthew Turk 26 Aug '11

26 Aug '11

Hi all, There was a service interruption; I'm having the ISP look into it, but it looks like for a couple days no emails were delivered to gmail.com addresses from the mailing lists. This now seems to be fixed, so if you have sent any emails over the last couple days you should feel free to re-send. (Many of the yt developers in particular use GMail to read their email.) -Matt

1 0

Making particle quantities into grid quantities
by Eric Hallman 25 Aug '11

25 Aug '11

Hello all, I looked through the previous threads on yt-users, and I don't see this particular problem described. Hoping for some help. So, the quantity dark_matter_density is a CIC-deposited particle quantity, which becomes a grid field. I would like to do something like this: for every grid voxel, calculate the mean dm particle *velocity* inside that voxel return as a grid field Is that simple using CIC_deposit? The only mean particle velocity I've seen used in yt/enzo before is the one calculated for halos, by using HOP or FOF identification. thanks! Eric

1 0

Introducing the yt Hub
by Britton Smith 24 Aug '11

24 Aug '11

Greetings! I am very excited to announce the yt Hub: http://hub.yt-project.org/. The yt Hub is a gathering place for all things related to running, analyzing, and presenting astrophysical simulations. Once upon a time, we had the Enzotools Barn, which was a place to share Enzo scripts unrelated to yt, including hosting of those scripts. The Barn was a minor success, but had a very limited scope and a somewhat clunky user experience. Now we have the yt Hub, where users can submit externally-hosted projects in a variety of categories: - yt scripts - Analysis and visualization tools and utilities - Simulation and data management - Scripts for making figures from published papers - News and announcements - General astrophysical utilities Users can create their own accounts and share anything they’ve created that might be useful to others. Currently, the preferred submission method is to create a repository on bitbucket.org and then submit the link to that. If you would like to host the repository for your contribution somewhere else, that’s fine, too. The forthcoming 2.2 release of yt will include a utility for automating the creation and uploading of a bitbucket.org repository as well as submitting that repository to the Hub. In addition, users may also subscribe to email announcements, in which they will receive an email with any new submissions from the previous day. Please, come check it out and contribute. The site is brand new, so feel free to send feedback if you encounter any oddities or think of improvements. The primary goal of yt has been to create a common analysis language for computational astrophysicists coming from different simulation codes. We hope that the yt Hub will serve as the meeting place for the conversation. Best regards, Britton Matt and the rest of the yt development team.

1 0

Re: [yt-users] coordinate question
by Elizabeth Tasker 24 Aug '11

24 Aug '11

Slight amendment: line plots imply this is an imshow thing, not a covering_grid problem. That actually makes it a python problem, not a yt one but I'd still really appreciate any insight. Thank you :) Elizabeth Tasker wrote: > Hi Matt, > > Thank you, that helped, but it did not entirely solve the problem. > What I've found is that a slice through my covering_grid does not look > the same as a slice done using pc.add_slice. > > I've attached links to two images to demonstrate the issue. > > http://i.imgur.com/zKVzY.png > > shows the slice through the extracted region with the positions of the > cores (found using extract_connected_sets on the whole hierarchy) > which don't line up. > > However, if you can imagine putting those same cores onto > > http://i.imgur.com/sOEvG.png > > which was made via add_slice, you can see they'd align perfectly. > > It looks like the extracted section is flipped through the line y = x. > Do you know if this is a feature of imshow or of covering_grid? I'm > thinking it *might* be the covering_grid that is inverted, since the > results from my data analysis don't look as expected (but it was a big > calculation that I could totally have just messed it up). > > I've put my calls for both below (and a more complete code is at the > bottom of the email). > > extractCube = pf.h.covering_grid(extract_level, > left_edge=extractLE, > right_edge=extractRE, > # How many dimensions along > each axis > dims=extractDims, > # And any fields to preload > (this is optional!) > num_ghost_zones = 3) > > pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)], > origin='lower', interpolation='nearest', aspect=aspect, extent=[min_x, > max_x, min_y, max_y]) > > Thanks! > > Elizabeth > > > Matthew Turk wrote: >> Hi Elizabeth, >> >> The imshow command in matplotlib normally puts the origin in the upper >> left. Change your call to imshow to include the argument: >> >> origin='lower' >> >> and it may fix your problem. If you look at the yt source, this is >> scattered throughout to account for this. You probably also want to >> supply: >> >> interpolation='nearest' >> >> -Matt >> >> On Mon, Aug 22, 2011 at 7:09 PM, Elizabeth Tasker >> <taskere(a)mcmaster.ca> wrote: >> >>> Hi, >>> >>> I feel I have a co-ordinate problem. >>> >>> I have a yt script that uses extract_connected_sets to find a bunch of >>> contoured objects, for which I calculate the centre of mass (core_com >>> below). >>> >>> I then cut out a covering_grid centred on each object that is 2 kpc in >>> width. >>> >>> I image the slice of the covering_grid through its and over-plot the >>> positions of the centre of mass of the contoured objects on it. >>> >>> The problem is, they don't line up! >>> >>> cloud50.png shows the process centred on object 50. Object 50 itself is >>> nicely over a blob but the others are randomly scattered. Although >>> this is >>> only a slice, the z-direction of the objects differs only slightly: it >>> shouldn't be possible to have an object sitting over nothing >>> (especially >>> when the slice effectively shows potential, which varies smoothly). >>> >>> cloud51.png shows the same process now centred on object 51. 51 is >>> now over >>> a clear blob, but you can see that the image has moved differently >>> to the >>> numbers. (The image has shifted down and the numbers way up). >>> >>> It looks to me that this should be flipped somehow (although >>> experimental >>> inverting the x-y axes have failed!), but I cannot see where the >>> mistake is. >>> >>> The (abbreviated) code looks like: >>> >>> contours = dd.extract_connected_sets("NegEscapeVelocity", 1, 30.0, >>> maxv, >>> log_space=False) >>> allcloudcores = contours[1][0] #cores defined by contour 0 >>> thiscore = allcloudcores[c] >>> >>> core_com = [] >>> for c in range(ncores): >>> core_com.append(thiscore.quantities["CenterOfMass"]()) >>> >>> >>> extractLE = [] >>> extractRE = [] >>> extractDims = [] >>> >>> min_x, max_x = thiscore.quantities["Extrema"]("x")[0] >>> min_y, max_y = thiscore.quantities["Extrema"]("y")[0] >>> min_z, max_z = thiscore.quantities["Extrema"]("z")[0] >>> >>> extractLE.append(max(min_x-1.0, 0.0)) >>> extractLE.append(max(min_y-1.0, 0.0)) >>> extractLE.append(max(min_z-1.0, 0.0)) >>> >>> extractRE.append(min(max_x+1.0, thiscore.pf.domain_right_edge[0])) >>> extractRE.append(min(max_y+1.0, thiscore.pf.domain_right_edge[1])) >>> extractRE.append(min(max_z+1.0, thiscore.pf.domain_right_edge[2])) >>> >>> for dim in range(3): >>> >>> extractDims.append(round((extractRE[dim]-extractLE[dim])/cellsize)) >>> >>> extractCube = pf.h.covering_grid(extract_level, >>> left_edge=extractLE, >>> right_edge=extractRE, >>> dims=extractDims, >>> num_ghost_zones = 3) >>> >>> plotfig = pylab.figure() >>> pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)], >>> >>> extent=[extractLE[0], extractRE[0], extractLE[1], extractRE[1]]) >>> colorbar = pylab.colorbar() >>> colorbar.set_label("Negative escape velocity [km/s]") >>> pylab.xlabel('x [kpc]') >>> pylab.ylabel('y [kpc]') >>> >>> for m in range(ncores): >>> pylab.annotate('%s' % (m), xy=(core_com[m][0], core_com[m][1]), >>> xycoords='data') >>> >>> pylab.savefig('clouds_novel%s' % (c)) >>> >>> >>> >>> >>> Is this a problem of where the "zero" point is in yt / enzo / >>> python? I was >>> assuming (0,0,0) is the bottom left? >>> >>> Elizabeth >>> >>> _______________________________________________ >>> yt-users mailing list >>> yt-users(a)lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >>> >>> >>> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

2 2

Re: [yt-users] coordinate question
by Elizabeth Tasker 23 Aug '11

23 Aug '11

Hi Matt, Thank you, that helped, but it did not entirely solve the problem. What I've found is that a slice through my covering_grid does not look the same as a slice done using pc.add_slice. I've attached links to two images to demonstrate the issue. http://i.imgur.com/zKVzY.png shows the slice through the extracted region with the positions of the cores (found using extract_connected_sets on the whole hierarchy) which don't line up. However, if you can imagine putting those same cores onto http://i.imgur.com/sOEvG.png which was made via add_slice, you can see they'd align perfectly. It looks like the extracted section is flipped through the line y = x. Do you know if this is a feature of imshow or of covering_grid? I'm thinking it *might* be the covering_grid that is inverted, since the results from my data analysis don't look as expected (but it was a big calculation that I could totally have just messed it up). I've put my calls for both below (and a more complete code is at the bottom of the email). extractCube = pf.h.covering_grid(extract_level, left_edge=extractLE, right_edge=extractRE, # How many dimensions along each axis dims=extractDims, # And any fields to preload (this is optional!) num_ghost_zones = 3) pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)], origin='lower', interpolation='nearest', aspect=aspect, extent=[min_x, max_x, min_y, max_y]) Thanks! Elizabeth Matthew Turk wrote: > Hi Elizabeth, > > The imshow command in matplotlib normally puts the origin in the upper > left. Change your call to imshow to include the argument: > > origin='lower' > > and it may fix your problem. If you look at the yt source, this is > scattered throughout to account for this. You probably also want to > supply: > > interpolation='nearest' > > -Matt > > On Mon, Aug 22, 2011 at 7:09 PM, Elizabeth Tasker > <taskere(a)mcmaster.ca> wrote: > >> Hi, >> >> I feel I have a co-ordinate problem. >> >> I have a yt script that uses extract_connected_sets to find a bunch of >> contoured objects, for which I calculate the centre of mass (core_com >> below). >> >> I then cut out a covering_grid centred on each object that is 2 kpc in >> width. >> >> I image the slice of the covering_grid through its and over-plot the >> positions of the centre of mass of the contoured objects on it. >> >> The problem is, they don't line up! >> >> cloud50.png shows the process centred on object 50. Object 50 itself is >> nicely over a blob but the others are randomly scattered. Although >> this is >> only a slice, the z-direction of the objects differs only slightly: it >> shouldn't be possible to have an object sitting over nothing (especially >> when the slice effectively shows potential, which varies smoothly). >> >> cloud51.png shows the same process now centred on object 51. 51 is >> now over >> a clear blob, but you can see that the image has moved differently to >> the >> numbers. (The image has shifted down and the numbers way up). >> >> It looks to me that this should be flipped somehow (although >> experimental >> inverting the x-y axes have failed!), but I cannot see where the >> mistake is. >> >> The (abbreviated) code looks like: >> >> contours = dd.extract_connected_sets("NegEscapeVelocity", 1, 30.0, maxv, >> log_space=False) >> allcloudcores = contours[1][0] #cores defined by contour 0 >> thiscore = allcloudcores[c] >> >> core_com = [] >> for c in range(ncores): >> core_com.append(thiscore.quantities["CenterOfMass"]()) >> >> >> extractLE = [] >> extractRE = [] >> extractDims = [] >> >> min_x, max_x = thiscore.quantities["Extrema"]("x")[0] >> min_y, max_y = thiscore.quantities["Extrema"]("y")[0] >> min_z, max_z = thiscore.quantities["Extrema"]("z")[0] >> >> extractLE.append(max(min_x-1.0, 0.0)) >> extractLE.append(max(min_y-1.0, 0.0)) >> extractLE.append(max(min_z-1.0, 0.0)) >> >> extractRE.append(min(max_x+1.0, thiscore.pf.domain_right_edge[0])) >> extractRE.append(min(max_y+1.0, thiscore.pf.domain_right_edge[1])) >> extractRE.append(min(max_z+1.0, thiscore.pf.domain_right_edge[2])) >> >> for dim in range(3): >> >> extractDims.append(round((extractRE[dim]-extractLE[dim])/cellsize)) >> >> extractCube = pf.h.covering_grid(extract_level, >> left_edge=extractLE, >> right_edge=extractRE, >> dims=extractDims, >> num_ghost_zones = 3) >> >> plotfig = pylab.figure() >> pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)], >> >> extent=[extractLE[0], extractRE[0], extractLE[1], extractRE[1]]) >> colorbar = pylab.colorbar() >> colorbar.set_label("Negative escape velocity [km/s]") >> pylab.xlabel('x [kpc]') >> pylab.ylabel('y [kpc]') >> >> for m in range(ncores): >> pylab.annotate('%s' % (m), xy=(core_com[m][0], core_com[m][1]), >> xycoords='data') >> >> pylab.savefig('clouds_novel%s' % (c)) >> >> >> >> >> Is this a problem of where the "zero" point is in yt / enzo / python? >> I was >> assuming (0,0,0) is the bottom left? >> >> Elizabeth >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> >> > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >

1 0

line callback
by Luigi Iapichino 23 Aug '11

23 Aug '11

Dear all, I would like to overplot a line to a slice of mine. I use the line callback, for example with the following sintax: p.modify["line"]((0,639),(30,30)) if I have well understood, the two pairs of numbers are pixel-based coordinates. I have a few questions: 1) where is the range of these number set (i.e., the image size in pixel), and how can I eventually modify it? 2) Is it any simple way to define the begin and end points of a line in other coordinates? Code coordinates from 0 to 1 would be enough; 3) How do I modify the features of the line (e.g. thickness, color)? Thanks in advance, Luigi -- --------------------------------------------------------------- Luigi Iapichino Zentrum für Astronomie der Universität Heidelberg Institut für Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi(a)uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/

2 2

coordinate question
by Elizabeth Tasker 23 Aug '11

23 Aug '11

Hi, I feel I have a co-ordinate problem. I have a yt script that uses extract_connected_sets to find a bunch of contoured objects, for which I calculate the centre of mass (core_com below). I then cut out a covering_grid centred on each object that is 2 kpc in width. I image the slice of the covering_grid through its and over-plot the positions of the centre of mass of the contoured objects on it. The problem is, they don't line up! cloud50.png shows the process centred on object 50. Object 50 itself is nicely over a blob but the others are randomly scattered. Although this is only a slice, the z-direction of the objects differs only slightly: it shouldn't be possible to have an object sitting over nothing (especially when the slice effectively shows potential, which varies smoothly). cloud51.png shows the same process now centred on object 51. 51 is now over a clear blob, but you can see that the image has moved differently to the numbers. (The image has shifted down and the numbers way up). It looks to me that this should be flipped somehow (although experimental inverting the x-y axes have failed!), but I cannot see where the mistake is. The (abbreviated) code looks like: contours = dd.extract_connected_sets("NegEscapeVelocity", 1, 30.0, maxv, log_space=False) allcloudcores = contours[1][0] #cores defined by contour 0 thiscore = allcloudcores[c] core_com = [] for c in range(ncores): core_com.append(thiscore.quantities["CenterOfMass"]()) extractLE = [] extractRE = [] extractDims = [] min_x, max_x = thiscore.quantities["Extrema"]("x")[0] min_y, max_y = thiscore.quantities["Extrema"]("y")[0] min_z, max_z = thiscore.quantities["Extrema"]("z")[0] extractLE.append(max(min_x-1.0, 0.0)) extractLE.append(max(min_y-1.0, 0.0)) extractLE.append(max(min_z-1.0, 0.0)) extractRE.append(min(max_x+1.0, thiscore.pf.domain_right_edge[0])) extractRE.append(min(max_y+1.0, thiscore.pf.domain_right_edge[1])) extractRE.append(min(max_z+1.0, thiscore.pf.domain_right_edge[2])) for dim in range(3): extractDims.append(round((extractRE[dim]-extractLE[dim])/cellsize)) extractCube = pf.h.covering_grid(extract_level, left_edge=extractLE, right_edge=extractRE, dims=extractDims, num_ghost_zones = 3) plotfig = pylab.figure() pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)], extent=[extractLE[0], extractRE[0], extractLE[1], extractRE[1]]) colorbar = pylab.colorbar() colorbar.set_label("Negative escape velocity [km/s]") pylab.xlabel('x [kpc]') pylab.ylabel('y [kpc]') for m in range(ncores): pylab.annotate('%s' % (m), xy=(core_com[m][0], core_com[m][1]), xycoords='data') pylab.savefig('clouds_novel%s' % (c)) Is this a problem of where the "zero" point is in yt / enzo / python? I was assuming (0,0,0) is the bottom left? Elizabeth

2 1

creating sunrise files from RAMSES snapshot
by Robert Feldmann 22 Aug '11

22 Aug '11

Hi, I am trying to create SUNRISE files for a RAMSES snapshot. I am using the latest stable version of YT ("2.1stable"). I can read the RAMSES snapshot, but the sunrise_exporter routine fails. The reason, it seems, is that it wants to access a field "InitialTime" that actually does not exist (see below). Is there somewhere some additional information about how to convert RAMSES to SUNRISE using YT? I could not find much (that includes searching the mailing lists). Thanks Robert >>> pf = load("output_00105/info_00105.txt") output_00105/amr_00105.out00001 yt : [INFO ] 2011-08-21 00:09:47,343 Parameters: current_time = -1.23236270587e+17 yt : [INFO ] 2011-08-21 00:09:47,343 Parameters: domain_dimensions = [2 2 2] yt : [INFO ] 2011-08-21 00:09:47,344 Parameters: domain_left_edge = [ 0. 0. 0.] yt : [INFO ] 2011-08-21 00:09:47,344 Parameters: domain_right_edge = [ 1. 1. 1.] yt : [INFO ] 2011-08-21 00:09:47,344 Parameters: cosmological_simulation = 1 yt : [INFO ] 2011-08-21 00:09:47,345 Parameters: current_redshift = 1.00027409463 yt : [INFO ] 2011-08-21 00:09:47,345 Parameters: omega_lambda = 0.759999990463 yt : [INFO ] 2011-08-21 00:09:47,345 Parameters: omega_matter = 0.239999994636 yt : [INFO ] 2011-08-21 00:09:47,345 Parameters: hubble_constant = 73.0 Now, when I try the following I get an error >>> from yt.analysis_modules.sunrise_export import sunrise_exporter >>> sunrise_exporter.export_to_sunrise(pf,"analysis/yt/HYDRO_L2_18_GF_epsstar0d1") yt : [INFO ] 2011-08-21 00:11:30,744 Re-gridding level 0: 1 octree grids Re-gridding 100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 ... Re-gridding 100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:0 yt : [INFO ] 2011-08-21 00:11:46,711 Final grid count: 302 yt : [INFO ] 2011-08-21 00:11:46,775 Re-gridding level 16: 59069 octree grids Re-gridding 100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:0 yt : [INFO ] 2011-08-21 00:11:47,093 Final grid count: 153 yt : [INFO ] 2011-08-21 00:11:52,568 Getting field particle_type from 2894 yt : [INFO ] 2011-08-21 00:11:52,760 Getting field particle_position_x from 2894 yt : [INFO ] 2011-08-21 00:11:52,951 Getting field particle_position_y from 2894 yt : [INFO ] 2011-08-21 00:11:53,141 Getting field particle_position_z from 2894 yt : [INFO ] 2011-08-21 00:11:53,344 Getting field particle_velocity_x from 2894 yt : [INFO ] 2011-08-21 00:11:53,542 Getting field particle_velocity_y from 2894 yt : [INFO ] 2011-08-21 00:11:53,739 Getting field particle_velocity_z from 2894 --------------------------------------------------------------------------- KeyError Traceback (most recent call last) /d/scratch39/feldmann/local/yt/yt-x86_64/src/yt-hg/scripts/iyt in <module>() ----> 1 2 3 4 5 /d/scratch39/feldmann/local/yt/yt-x86_64/src/yt-hg/yt/analysis_modules/sunrise_export/sunrise_exporter.pyc in export_to_sunrise(pf, fn, write_particles, sub gion_bounds, particle_mass, particle_pos, particle_age, particle_metal) 110 # Velocity is cm/s, we want it to be kpc/yr 111 vel *= (pf["kpc"]/pf["cm"]) / (365*24*3400.) --> 112 age = pf["years"] * (pf["InitialTime"] - reg["creation_time"][pi]) 113 creation_time = reg["creation_time"][pi] * pf["years"] 114 /d/scratch39/feldmann/local/yt/yt-x86_64/src/yt-hg/yt/data_objects/static_output.pyc in __getitem__(self, key) 117 self.conversion_factors]: 118 if key in d: return d[key] --> 119 raise KeyError(key) 120 121 def keys(self): KeyError: 'InitialTime' --- These are the available fields in pf pf._StaticOutput__hierarchy pf.__repr__ pf._setup_nounits_units pf.has_key pf.__class__ pf.__setattr__ pf.basename pf.hierarchy pf.__delattr__ pf.__sizeof__ pf.conversion_factors pf.hubble_constant pf.__dict__ pf.__str__ pf.cosmological_simulation pf.keys pf.__doc__ pf.__subclasshook__ pf.current_redshift pf.omega_lambda pf.__format__ pf.__weakref__ pf.current_time pf.omega_matter pf.__getattribute__ pf._fieldinfo_class pf.data_style pf.parameter_filename pf.__getitem__ pf._get_hierarchy pf.dimensionality pf.parameters pf.__hash__ pf._handle pf.directory pf.print_key_parameters pf.__init__ pf._hash pf.domain_dimensions pf.ramses_tree pf.__iter__ pf._hierarchy_class pf.domain_left_edge pf.refine_by pf.__metaclass__ pf._instantiated pf.domain_right_edge pf.storage_filename pf.__module__ pf._is_valid pf.field_info pf.time_units pf.__new__ pf._parse_parameter_file pf.fullpath pf.unique_identifier pf.__reduce__ pf._set_hierarchy pf.get_smallest_appropriate_unit pf.units pf.__reduce_ex__ pf._set_units pf.h

3 5

shape mismatch?
by david collins 20 Aug '11

20 Aug '11

Hi, all-- I have this simulation that has a single subgrid. 64^3 root, 24 zone root grid (from 0.15625 to 0.34375 along each axis) With the old output style (enzo1.0.1) this doesn't give me any problems. But with the new output version (packed IO, newgridio-no, in mhdctmerge) I get the following message3 <trace> >>> pf = MyOutputs.FileStaticOutputFourPi('/Users/dccollins/ThisScratch/param//Turbulence/t64_1lev_m/./DD0001/data0001') >>> pf.h Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/dccollins/local/src/yt-hg/yt/data_objects/static_output.py", line 159, in _get_hierarchy self.__hierarchy = self._hierarchy_class(self, data_style=self.data_style) File "/Users/dccollins/local/src/yt-hg/yt/frontends/enzo/data_structures.py", line 158, in __init__ AMRHierarchy.__init__(self, pf, data_style) File "/Users/dccollins/local/src/yt-hg/yt/data_objects/hierarchy.py", line 70, in __init__ self._parse_hierarchy() File "/Users/dccollins/local/src/yt-hg/yt/frontends/enzo/data_structures.py", line 220, in _parse_hierarchy if self._parse_binary_hierarchy(): return File "/Users/dccollins/local/src/yt-hg/yt/frontends/enzo/data_structures.py", line 295, in _parse_binary_hierarchy self.grid_dimensions[:] = f["/ActiveDimensions"][:] ValueError: shape mismatch: objects cannot be broadcast to a single shape >>> pdb.pm() > /Users/dccollins/local/src/yt-hg/yt/frontends/enzo/data_structures.py(295)_parse_binary_hierarchy() -> self.grid_dimensions[:] = f["/ActiveDimensions"][:] (Pdb) self.grid_dimensions array([[1, 1, 1], [1, 1, 1]], dtype=int32) (Pdb) f['/ActiveDimensions'][:] array([[64, 64, 64], [32, 32, 16], [32, 32, 16]], dtype=int32) (Pdb) </trace> Why is self.grid_dimensions a 2d array? Why don't these things match? Thanks! d. -- Sent from my computer.

3 2

The yt Project
by Matthew Turk 19 Aug '11

19 Aug '11

Hi all, In keeping with the current direction of the yt project, on the yt-dev mailing list there was some discussion recently about the mission statement of the project, the scope, and the directions we want to take it in the future. These goals have grown with time and the scope of the project has expanded, as the mission statement on the front page indicates. In keeping with this, Britton Smith proposed on yt-dev yesterday that we migrate from the ".enzotools.org" domain toward something less focused on a particular simulation code. Today we have migrated the domains over to yt-project.org. All of your existing links should transparently continue working, but from now on we're going to be identifying as yt-project.org, paste.yt-project.org, and hg.yt-project.org rather than the previous .enzotools.org domains. There are a few new interesting things coming down the pipe as well with this transition. As always, if you'd like to chat about this further, feel free to reply to this message, stop by the yt-dev mailing list, or drop in on IRC. If you run into any glitches with the changeover, let me know (I'm the one behind the steering wheel for the DNS and service provider stuff) so that I can try to make it as smooth as possible. Thanks very much, Matt

1 0

problem accessing EOSCriticalDensity parameter (enzo)
by j s oishi 18 Aug '11

18 Aug '11

Hi all, I am trying to reach Enzo's EOSCriticalDensity parameter in my pf within yt (hg hash 486d7131f1c2) . For some reason, it throws a KeyError, even though grepping EOSCriticalDensity in the DD0001/data0001 file turns it right up: $ grep EOSCriticalDensity DD0001/data0001 EOSCriticalDensity = 1e-13 I have deleted the .yt file, but to no avail. The error message is: In [1]: pf['EOSCriticalDensity'] --------------------------------------------------------------------------- KeyError Traceback (most recent call last) /home/jsoishi/build/yt-unknown/src/yt-hg/yt/utilities/command_line.pyc in <module>() ----> 1 2 3 4 5 /home/jsoishi/build/yt-unknown/src/yt-hg/yt/data_objects/static_output.pyc in __getitem__(self, key) 118 self.conversion_factors]: 119 if key in d: return d[key] --> 120 raise KeyError(key) 121 122 def keys(self): KeyError: 'EOSCriticalDensity' Can anyone provide insight? I feel fairly certain I'm doing something dumb, but I don't see what. thanks, jeff

4 9

Re: [yt-users] Images of extracted regions
by Elizabeth Tasker 18 Aug '11

18 Aug '11

I've just seen that "data_source" is an option for add_projection, but it still fails with "AttributeError: 'AMRCoveringGrid' object has no attribute '_get_cut_mask'" Elizabeth Elizabeth Tasker wrote: > Hi Britton, > > Sorry, could you give me an example of how the call should look? > > I tried: > > p = pc.add_slice("NegEscapeVelocity", 2, field_parameters = > {'disk_radius':profile["DiskRadius"], > 'potential':profile["PotentialField"]}, data_source=extractCube) > > which fails because data_source is unrecognised (and indeed, isn't in > the function description: > http://yt.enzotools.org/doc/reference/api/generated/yt.visualization.plot_c…) > > > And I tried: > > p = pc.add_slice(extractCube, "NegEscapeVelocity", 2) > > > which also failed with: > > > ValueError Traceback (most recent call > last) > > /1/home/taskere/yt/scripts/iyt in <module>() > ----> 1 > 2 > 3 > 4 > 5 > /1/home/taskere/yt/yt/visualization/plot_collection.py in > add_slice(self, field, axis, coord, center, use_colorbar, figure, > axes, fig_size, periodic, obj, > field_parameters) > 402 if field_parameters == None: field_parameters = > {} 403 obj = > self.pf.hierarchy.slice(axis, coord, > field, --> > 404 center=center, > **field_parameters) > 405 p = > self._add_plot(SlicePlot( > > 406 obj, field, > use_colorbar=use_colorbar, > /1/home/taskere/yt/yt/data_objects/data_containers.py in > __init__(self, axis, coord, fields, center, pf, node_name, **kwargs) > 935 self.coord = coord > 936 if node_name is False: > --> 937 self._refresh_data() > 938 else: > 939 if node_name is True: self._deserialize() > > /1/home/taskere/yt/yt/data_objects/data_containers.py in > _refresh_data(self) > 273 """ > 274 self.clear_data() > --> 275 self.get_data() > 276 > 277 def keys(self): > > /1/home/taskere/yt/yt/data_objects/data_containers.py in > get_data(self, fields) > 780 # We take a 3-tuple of the coordinate we want to slice > through, as well > > 781 # as the axis we're slicing along > > --> 782 self._get_list_of_grids() > 783 if not self.has_key('pdx'): > 784 self._generate_coords() > > /1/home/taskere/yt/yt/data_objects/data_containers.py in > _get_list_of_grids(self) > 994 > 995 def _get_list_of_grids(self): > --> 996 goodI = ((self.pf.h.grid_right_edge[:,self.axis] > > self.coord) > 997 & (self.pf.h.grid_left_edge[:,self.axis] <= > self.coord )) > 998 self._grids = self.pf.h.grids[goodI] # Using sources > not hierarchy > > ValueError: setting an array element with a sequence. > > > > Elizabeth > > > > > > Britton Smith wrote: >> The first is definitely possible. Just add data_source=extractCube >> to your call to add_projection or add_slice or whatever. The second >> probably won't work because the projection or slice routine will look >> for other things like cell dxs that won't be present from just a >> similarly sized array. If you want to do something like that, you're >> probably better off making a new field and then projecting that with >> the above data_source keyword argument in there. >> >> Britton >> >> On Thu, Aug 18, 2011 at 10:59 AM, Elizabeth Tasker >> <taskere(a)mcmaster.ca <mailto:taskere@mcmaster.ca>> wrote: >> >> Hi, >> >> Is it possible to make a slice or projection of a extracted, fixed >> resolution region? i.e. the resultant object of: >> >> extractCube = pf.h.covering_grid(extract_level, >> left_edge=extractLE, >> right_edge=extractRE, >> # How many dimensions along >> each axis >> dims=extractDims, >> # And any fields to preload >> (this is optional!) >> fields=["PotentialField"], >> num_ghost_zones = 3) >> >> >> Or of an array later made to the same size? e.g. >> >> cloud = na.zeros(extractCube["x-velocity"].shape, dtype='float64') >> >> >> Elizabeth >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org <mailto:yt-users@lists.spacepope.org> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

1 0

Images of extracted regions
by Elizabeth Tasker 18 Aug '11

18 Aug '11

Hi, Is it possible to make a slice or projection of a extracted, fixed resolution region? i.e. the resultant object of: extractCube = pf.h.covering_grid(extract_level, left_edge=extractLE, right_edge=extractRE, # How many dimensions along each axis dims=extractDims, # And any fields to preload (this is optional!) fields=["PotentialField"], num_ghost_zones = 3) Or of an array later made to the same size? e.g. cloud = na.zeros(extractCube["x-velocity"].shape, dtype='float64') Elizabeth

3 3

data.LeftEdge with slice?
by Elizabeth Tasker 18 Aug '11

18 Aug '11

Hi, I have a field which uses data.LeftEdge, but when I try to create a slice from this, it says: AttributeError: 'AMRSlice' object has no attribute 'LeftEdge' Is this because the data is not 3d? I was trying valiantly to avoid having to load all that in! Elizabeth

2 2

Re: [yt-users] passing parameters to 'ray'
by Elizabeth Tasker 17 Aug '11

17 Aug '11

Hi Sam, OK, I've succeeded in breaking your improved script. When you try and set both parameter and spatial validators, the code stops recognising them. So: add_field("RayTest", function=_RayTest, validators=[ValidateParameter("disk_vector")]) works while add_field("RayTest", function=_RayTest, validators=[ValidateParameter("disk_vector"), ValidateParameter("disk_center"), ValidateSpatial(1, ["x-velocity", "y-velocity", "z-velocity", "x", "y", "z"])]) does not.Which it why it didn't work in my longer script. Perhaps I've put the format in incorrectly? Elizabeth Elizabeth Tasker wrote: > Hi Sam, > > Thank you -- my test script now works fine but I've managed to break > my longer one so completely it's become impossible to test anything. > Oops. However, I think when I tried the method below originally, I put > the set_field_parameters in the wrong place, which would explain why > they didn't work. > > Thanks loads for the example. > > Elizabeth > > Sam Skillman wrote: >> Hi Elizabeth, >> >> So the problem is that when you add_field and ask to validate the >> height_vector, it doesn't exist yet. I believe you can get the >> desired behavior with: >> >> from yt.mods import * >> >> def _RayTest(field, data): >> >> center = data.get_field_parameter("center") >> h_vec = na.array(data.get_field_parameter("height_vector")) >> >> print "center :", center, "h_vec: ", h_vec >> >> return data["Density"] >> >> add_field("RayTest", function=_RayTest) >> >> # Grab data >> fn = "GravPotential/DD0301/GT_BTAccel_256AMR4_PeHeat_sf5_SNe_0301" >> pf = load(fn) >> ray1 = pf.h.ray((2.0, 2.0 ,2.0), (12.0, 12.0, 12.0)) >> ray1.set_field_parameter('height_vector',na.array([0.,0.,1.])) >> ray1.set_field_parameter('center',[0.5]*3) >> ray1["RayTest"] >> >> When I run this I get: center : [0.5, 0.5, 0.5] h_vec: [ 0. 0. 1.] >> >> I'm not sure what dd was in your dd.center since dd wasn't defined in >> that script, but you should be able to set center to whatever you >> want here. I also changed density to Density. >> Best, >> Sam >> >> On Wed, Aug 10, 2011 at 9:36 AM, Elizabeth Tasker >> <taskere(a)mcmaster.ca <mailto:taskere@mcmaster.ca>> wrote: >> >> Hi Matt, >> >> I think this script explains what I mean. When I run it, I get: >> >> /1/home/taskere/yt/yt/data_objects/field_info_container.py in >> __call__(self, data) >> 357 doesnt_have.append(p) >> 358 if len(doesnt_have) > 0: >> --> 359 raise NeedsParameter(doesnt_have) >> 360 return True >> 361 >> >> NeedsParameter: (['height_vector']) >> >> >> As a side note, I think 'ray' sets its own value for the field >> parameter, "center", making it the start of the ray. If that's >> true, does it have problems for calling radius? e.g. >> >> ray["Radius"] >> >> where radius would need to be the center of the object, not >> necessarily the start of the ray? (This particular issue wouldn't >> affect me, but I thought it might bite someone later). >> >> Elizabeth >> >> >> >> Matthew Turk wrote: >> >> >> Hi Elizabeth, >> >> Could you elaborate on what you mean, and provide an example >> script? >> >> Thanks, >> >> -Matt >> >> On Aug 10, 2011 7:22 AM, "Elizabeth Tasker" >> <taskere(a)mcmaster.ca <mailto:taskere@mcmaster.ca> >> <mailto:taskere@mcmaster.ca <mailto:taskere@mcmaster.ca>>> >> wrote: >> > Hi, >> > >> > I'm having problems passing parameters to a ray object. I'm >> trying: >> > >> > ray1 = pf.h.ray( com[c], com[nearestcore], field_parameters = >> > {'height_vector':na.array([0,0,1]), 'center':dd.center}) >> > Omega0 = ray1["Omega"] >> > >> > and I also tried out: >> > >> > ray1.set_field_parameter("height_vector", na.array([0,0,1])) >> > ray1.set_field_parameter("center", dd.center) >> > >> > But it can't recognise them. >> > >> > Elizabeth >> > _______________________________________________ >> > yt-users mailing list >> > yt-users(a)lists.spacepope.org >> <mailto:yt-users@lists.spacepope.org> >> <mailto:yt-users@lists.spacepope.org >> <mailto:yt-users@lists.spacepope.org>> >> >> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> <mailto:yt-users@lists.spacepope.org> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org <mailto:yt-users@lists.spacepope.org> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

3 4

ray objects
by Elizabeth Tasker 17 Aug '11

17 Aug '11

Hi, When you create a ray object with yt, e.g. ray1 = pf.h.ray([10,16,16], [10.3,16.1,16]) I was expecting to get the values of the cells that lie inbetween those two sets of co-ordinates. Instead, it looks like the first two values back at the start and end points. .e.g.: -------> print(ray1["x"]) Warning: divide by zero encountered in divide Warning: invalid value encountered in multiply Warning: divide by zero encountered in divide Warning: invalid value encountered in multiply yt : [INFO ] 2011-08-16 14:47:27,962 Getting field t from 92 yt : [INFO ] 2011-08-16 14:47:28,972 Getting field x from 92 [ 10.0078125 10.30078125 10.0234375 10.0390625 10.0390625 10.0546875 10.0703125 10.0859375 10.0859375 10.1015625 10.1171875 10.1328125 10.1328125 10.1484375 10.1640625 10.17578125 10.18359375 10.18359375 10.19140625 10.19921875 10.20703125 10.20703125 10.21484375 10.22265625 10.23046875 10.23046875 10.23828125 10.24609375 10.25390625 10.25390625 10.26171875 10.26953125 10.27734375 10.27734375 10.28515625 10.29296875] In [53]: print ray1["y"] -------> print(ray1["y"]) yt : [INFO ] 2011-08-16 14:48:23,698 Getting field y from 92 [ 16.0078125 16.09765625 16.0078125 16.0078125 16.0234375 16.0234375 16.0234375 16.0234375 16.0390625 16.0390625 16.0390625 16.0390625 16.0546875 16.0546875 16.0546875 16.05859375 16.05859375 16.06640625 16.06640625 16.06640625 16.06640625 16.07421875 16.07421875 16.07421875 16.07421875 16.08203125 16.08203125 16.08203125 16.08203125 16.08984375 16.08984375 16.08984375 16.08984375 16.09765625 16.09765625 16.09765625] Is that right? Should I ignore the first two values of ray1 when I'm examining the data, e.g. ray1["Density"]? Thanks! Elizabeth

4 5

Trouble installing yt
by Nathan Goldbaum 16 Aug '11

16 Aug '11

Hi all, I'm having trouble installing yt from the install script. This is on a small cluster here at UCSC. The install script fails while trying to install libpng The terminal output from my install session is located here: http://paste.enzotools.org/show/1746/ And the contents of my yt_install.log are located here: http://paste.enzotools.org/show/1747/ Any thoughts as to why the install script is failing? Best, Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum(a)ucolick.org http://www.ucolick.org/~goldbaum

2 2

Clump finding and mpi4py
by Eve Lee 15 Aug '11

15 Aug '11

Hello, May I ask if the current version of yt supports parallelization of clump finding routine? When I use mpirun.py -np (whatever number) python (name of my clump finding routine) (some arguments my routine requires) --parallel, I keep getting the following error: Traceback (most recent call last): File "find_clumps.py", line 32, in <module> amods.level_sets.find_clumps(base, c_min, c_max, step) File "/home/jchong/yt/new_dev/xxx/yt-x86_64/src/yt-hg/yt/analysis_modules/level_sets/clump_handling.py", line 188, in find_clumps elif (child._isValid()): File "/home/jchong/yt/new_dev/xxx/yt-x86_64/src/yt-hg/yt/analysis_modules/level_sets/clump_handling.py", line 143, in _isValid self.function_value = eval(self.function) File "<string>", line 1, in <module> File "/home/jchong/yt/new_dev/xxx/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.py", line 86, in __call__ self.func(e, *args, **kwargs) File "/home/jchong/yt/new_dev/xxx/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.py", line 347, in _IsBound bv_x,bv_y,bv_z = data.quantities["BulkVelocity"]() AttributeError: 'FieldDetector' object has no attribute 'quantities' This version is updated to changeset 4457:bf868d1a8f02. I have no problem running the same routine serially but it would be nice if I can run parallel to save some time. Below is my clump finding routine if it helps: from yt.mods import * import sys #Find and save clumps #Read in the command-line-passed arguments datadir = sys.argv[1] pltdir = sys.argv[2] datanum_start = int(sys.argv[3]) datanum_end = int(sys.argv[4]) datanum_step = int(sys.argv[5]) for i in range(datanum_start, datanum_end, datanum_step): pf = load(datadir+"DD%04i/data%04i" %(i,i)) center = [0.5, 0.5, 0.5] radius = 1.0 sp = pf.h.sphere(center, radius) particles = pf.h.find_particles_by_type(4) if type(particles) != types.NoneType: field = "Matter_Density" #Use both new_function = 'self.data.quantities["IsBound"](truncate=True,include_thermal_energy=False) > 1.0' else: field = "Density" new_function = 'self.data.quantities["IsBound"](truncate=True,include_thermal_energy=False,include_particles=False) > 1.0' c_min = 10**na.floor(na.log10(sp[field]).min()+1) c_max = 10**na.floor(na.log10(sp[field]).max()+1) step = 10 #Find clumps base = amods.level_sets.Clump(sp, None, field, function=new_function) amods.level_sets.find_clumps(base, c_min, c_max, step) #Save clumps pf.h.save_object(base, "Clump") Thanks! Best Regards, Eve

2 1

change in add_projection/add_thin_projection for unweighted projections?
by Christine Simpson 15 Aug '11

15 Aug '11

Hi all, Has there been a change to the add_projection or add_thin_projection routines for unweighted projections? I have some projection scripts from ~a month ago that are all off by like 20 orders of magnitude on the color bar limits for unweighted projections. The only thing that makes sense to me is that yt is now dividing the line of sight integration by the depth of the projection. So it is sum(f(i)*dl(i))/sum(dl(i)) instead of sum(f(i)*dl(i)). Is that right? I don't think it used to do that. It's fine if that is now what it is doing, but I just want to make sure. I'm a little confused. Christine

2 7

pickle
by Elizabeth Tasker 11 Aug '11

11 Aug '11

Hi, (Another day a different problem!): I'd like to pickle the results from extract_connected_sets, but I can't seem to retrieve what I pickle properly. I have: contours = dd.extract_connected_sets("NegEscapeVelocity", 1, 30.0, maxv, log_space=False) cloudcores = contours[1][0] #cores defined by contour 0 file = open('testa.pickle','wb') cPickle.dump(cloudcores,file,protocol=-1) file.close() file = open('testa.pickle','rb') core = cPickle.load(file) file.close() But while: In [76]: cloudcores[40]["Density"] Out[76]: array([ 3.80336226e-23, 4.31254788e-23, 3.87927154e-23, ..., 1.26533774e-22, 2.13753864e-22, 2.74680682e-22]) In [77]: core[40]["Density"] --------------------------------------------------------------------------- KeyError Traceback (most recent call last) /1/home/taskere/yt/scripts/iyt in <module>() ----> 1 2 3 4 5 KeyError: 40 Is it not possible to pickle a contour object or is there something else I have to do when un-pickling? Thank you, Elizabeth

3 4

Visualizing clumps in 3D?
by Eve Lee 11 Aug '11

11 Aug '11

Hello, I'm using yt's clump find routine to locate clumps with embedded star particles in an Enzo stirred turbulent box with star formation, and I'm wondering if yt has the functionalities to visualize these clumps in 3D space rather than 2D projected contour lines. Is it possible to volume render just the clumps (not the whole box which seems like what yt's doing according to the documentation webpage) or better yet, make a 3D contour plot to visualize the clump hierarchy? Thanks. Best Regards, Eve

2 1

passing parameters to 'ray'
by Elizabeth Tasker 10 Aug '11

10 Aug '11

Hi, I'm having problems passing parameters to a ray object. I'm trying: ray1 = pf.h.ray( com[c], com[nearestcore], field_parameters = {'height_vector':na.array([0,0,1]), 'center':dd.center}) Omega0 = ray1["Omega"] and I also tried out: ray1.set_field_parameter("height_vector", na.array([0,0,1])) ray1.set_field_parameter("center", dd.center) But it can't recognise them. Elizabeth

3 4

ART simulations
by Mark Danovich 10 Aug '11

10 Aug '11

Hi, Is there any support for Daniel Ceverino's ART simulations and maybe some tutorial. I've seen code for reading in the data, but I don't know how to make it yt compatible. Thanks. -- Mark Danovich

2 1

Re: [yt-users] data along rays
by Elizabeth Tasker 09 Aug '11

09 Aug '11

Actually, I think it's because my covering_grid has no ghost zones. I'll add some in. E. Elizabeth Tasker wrote: > Hi Matt, > > Ah, great -- thank you. However, when I try to use it, the code chocks > on my 3d data. I have: > > add_field("Omega", function=_Omega, > validators=[ValidateParameter("height_vector"), > ValidateParameter("center"), ValidateSpatial(1, ["x-velocity", > "y-velocity", "z-velocity", "x", "y", "z"])]) > > and I get > > /1/home/taskere/yt/yt/data_objects/field_info_container.py in > __call__(self, data) > 411 if self.ghost_zones <= data._num_ghost_zones: > 412 return True > --> 413 raise NeedsGridType(self.ghost_zones,self.fields) > 414 > 415 class ValidateGridType(FieldValidator): > > NeedsGridType: (1, ['x-velocity', 'y-velocity', 'z-velocity', 'x', > 'y', 'z']) > > Did I get the syntax wrong? > > Elizabeth > > > Matthew Turk wrote: >> >> Hi Elizabeth, >> >> You have to use the ValidateSpatial validator to ensure that the data >> handed to te subroutine is 3D. >> >> -Matt >> >> On Aug 9, 2011 11:50 AM, "Elizabeth Tasker" <taskere(a)mcmaster.ca >> <mailto:taskere@mcmaster.ca>> wrote: >> > Hi, >> > >> > I have a mystery: >> > >> > Creating a ray via: >> > >> > ray = pf.h.ray( com[c], com[nearestcore]) >> > >> > and I want to get the effective potential along it, for which I have a >> > subrountine for. However, yr gets stuck here: >> > >> > if data.pf <http://data.pf>["HydroMethod"] == 2: >> > xvel[0:-1,0:-1,0:-1] = >> > >> 0.5*(data["x-velocity"][slice(None,-1,None),0:-1,0:-1]+data["x-velocity"][slice(1,None,None),0:-1,0:-1]) >> >> > >> > >> > I thought the problem was because a ray is a 1D data set and I was >> > trying to treat it like a 3D array, but what confuses me is that: >> > >> > ray["DivV"] >> > >> > works just fine but as the same sort of line within its definition. >> > >> > http://yt.enzotools.org/doc/reference/field_list.html#divv >> > >> > To make matters more confusing, if I copy out the definition of DivV >> > directly from universal_fields.py and implement it imaginatively as >> > DivV2, the code doesn't work, giving me: >> > >> > /1/home/taskere/yt/scripts/iyt in _DivV2(field, data) >> > 211 div_fac = 2.0 >> > 212 ds = div_fac * data['dx'].flat[0] >> > --> 213 f = data["x-velocity"][sl_right,1:-1,1:-1]/ds >> > 214 f -= data["x-velocity"][sl_left ,1:-1,1:-1]/ds >> > 215 if data.pf.dimensionality > 1: >> > >> > IndexError: too many indices >> > >> > >> > What magic line does yt have to allow DivV to work for a ray? >> > >> > Thanks, >> > >> > Elizabeth >> > >> > _______________________________________________ >> > yt-users mailing list >> > yt-users(a)lists.spacepope.org <mailto:yt-users@lists.spacepope.org> >> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

1 0

data along rays
by Elizabeth Tasker 09 Aug '11

09 Aug '11

Hi, I have a mystery: Creating a ray via: ray = pf.h.ray( com[c], com[nearestcore]) and I want to get the effective potential along it, for which I have a subrountine for. However, yr gets stuck here: if data.pf["HydroMethod"] == 2: xvel[0:-1,0:-1,0:-1] = 0.5*(data["x-velocity"][slice(None,-1,None),0:-1,0:-1]+data["x-velocity"][slice(1,None,None),0:-1,0:-1]) I thought the problem was because a ray is a 1D data set and I was trying to treat it like a 3D array, but what confuses me is that: ray["DivV"] works just fine but as the same sort of line within its definition. http://yt.enzotools.org/doc/reference/field_list.html#divv To make matters more confusing, if I copy out the definition of DivV directly from universal_fields.py and implement it imaginatively as DivV2, the code doesn't work, giving me: /1/home/taskere/yt/scripts/iyt in _DivV2(field, data) 211 div_fac = 2.0 212 ds = div_fac * data['dx'].flat[0] --> 213 f = data["x-velocity"][sl_right,1:-1,1:-1]/ds 214 f -= data["x-velocity"][sl_left ,1:-1,1:-1]/ds 215 if data.pf.dimensionality > 1: IndexError: too many indices What magic line does yt have to allow DivV to work for a ray? Thanks, Elizabeth

2 2

slice: quick question
by Elizabeth Tasker 05 Aug '11

05 Aug '11

Hi, Simple question, I think. In the definition of divV: http://yt.enzotools.org/doc/reference/field_list.html#divv How is the call for slice working: sl_left = slice(None,-2,None) sl_right = slice(2,None,None) and for Zeus: sl_left = slice(None,-2,None) sl_right = slice(1,-1,None) The documentation says the arguments should be axis & co-ordinate and then some options. I have failed to work out the syntax based on what I know the result must be! Thank you~ Elizabeth

2 2

reading RAMSES files - missing cosmological_simulation flag?
by Rok Roskar 05 Aug '11

05 Aug '11

hi there, trying to read a RAMSES output from a cosmological zoom simulation, I get the following perplexing error: >>> from yt.mods import * >>> sim = load("output_00422/info_00422.txt") output_00422/amr_00422.out00001 yt : [INFO ] 2011-08-05 15:13:45,236 Parameters: current_time = -2.10180018413e+16 yt : [INFO ] 2011-08-05 15:13:45,237 Parameters: domain_dimensions = [2 2 2] yt : [INFO ] 2011-08-05 15:13:45,237 Parameters: domain_left_edge = [ 0. 0. 0.] yt : [INFO ] 2011-08-05 15:13:45,238 Parameters: domain_right_edge = [ 1. 1. 1.] yt : [ERROR ] 2011-08-05 15:13:45,238 Missing cosmological_simulation in parameter file definition! this clearly is a cosmological simulation with the relevant parameters specified in the info*.txt file - is something else needed? Thanks, Rok

3 5

Re: [yt-users] velocity fields in yt
by Elizabeth Tasker 03 Aug '11

03 Aug '11

Although actually, "RadialVelocity" is one place where it would also be an issue. It doesn't look like that is corrected for Zeus, if x-velocity etc are still face-centred. Am I reading that right? Elizabeth Tasker wrote: > I was wondering if the x-velocity, y-velocity and z-velocity fields > themselves had been averaged to give a cell-centred quantity. There's > no need for them to be so, I just needed to know before I calculated a > cross-product to find the rotational potential of clouds I'd picked out. > > Thank you for the clarification :) > > Elizabeth > > > Matthew Turk wrote: >> Only in the DivV and VoritictySquared fields. Where else should it >> be made? >> >> On Wed, Aug 3, 2011 at 5:04 PM, Elizabeth Tasker >> <taskere(a)mcmaster.ca> wrote: >> >>> Hi, >>> >>> Quick question about the baryon velocity fields in yt: has any >>> correction >>> been made for the fact Zeus uses face-centred, not cell-centred, >>> velocities? >>> >>> Elizabeth >>> _______________________________________________ >>> yt-users mailing list >>> yt-users(a)lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >>> >>> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

3 3

velocity fields in yt
by Elizabeth Tasker 03 Aug '11

03 Aug '11

Hi, Quick question about the baryon velocity fields in yt: has any correction been made for the fact Zeus uses face-centred, not cell-centred, velocities? Elizabeth

2 2

Integration efforts between VisIt and Yt
by Harinarayan Krishnan 03 Aug '11

03 Aug '11

Hi Yt users, I am happy to announce that there is an effort underway to integrate Yt and VisIt (http://llnl.gov/visit). Once development is complete, you should be able to utilize VisIt's functionality seamlessly with Yt. We are also in the process of integrating Yt into VisIt. So for any VisIt users out there, the new features should make using VisIt a lot easier, if you are already comfortable with Yt. We would like a second of your time to fill out a quick survey in order to gauge your interest in these efforts. https://spreadsheets.google.com/a/lbl.gov/spreadsheet/viewform?hl=en_US&pli… Please note that there is a feature section where you can sound off on any features that you may have wanted either Yt or VisIt to provide. We would like to see where we can improve Yt, VisIt, or both. Thanks, Hari

1 0