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