yt-users November 2012

yt-users@python.org

19 participants
14 discussions

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

Variance in phase/profiles
by david collins 11 Apr '20

11 Apr '20

Hi, Everybody! Does anyone out there have a technique for getting the variance out of a profile object? A profile object is good at getting <X> vs. B, I'd then like to get < (X - <X>)^2 > vs B. Matt and I had spittballed the possibility some time ago, but I was wondering if anyone out there had successfully done it. Thanks, d. -- Sent from my computer.

6 8

Star Projections
by Munier Azzam Salem 05 Dec '12

05 Dec '12

Hi yt gurus, I've been making projections of star_density from enzo output files and they seem to be working out fine. However, wherever particles do not exist the background remains white instead of following my chosen colormap. Is there a way to paint these areas to follow the colormap? thanks! Munier I've attached an image of what gets plotted, and the relevant bits of my script are: *from yt.mods import ** * * *fName = "DD0006/test_sim_0006"* *var = "star_density"* *axis = 0* * * *pf = load(fName)* *pf.h* * * *pc = PlotCollection(pf)* *p = pc.add_projection(var,axis)* *#p.modify["particles"](1.0)* * * *radius = .02;* * * *pc.set_xlim(.5-radius,.5+radius)* *pc.set_ylim(.5-radius,.5+radius)* * * *pc.save(fName)* -- Munier A. Salem // 845.489.6450

5 11

Re: [yt-users] yt-users Digest, Vol 57, Issue 7
by Anna Rosen 26 Nov '12

26 Nov '12

Thanks, Andrew! It works now, I altered my yt-x86_64/src/yt-hg/yt/frontends/orion/fields.py to match yours. Changing add_orion_field to add_field corrects the problem. I'm not quite sure why though. On Nov 13, 2012, at 5:04 AM, yt-users-request(a)lists.spacepope.org wrote: > Send yt-users mailing list submissions to > yt-users(a)lists.spacepope.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > or, via email, send a message with subject or body 'help' to > yt-users-request(a)lists.spacepope.org > > You can reach the person managing the list at > yt-users-owner(a)lists.spacepope.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of yt-users digest..." > > > Today's Topics: > > 1. Orion Derived Fields (Anna Rosen) > 2. Re: Orion Derived Fields (Andrew Myers) > 3. Re: Strange Behaviour in ProjectionPlot (Patrick Rieser) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Nov 2012 16:04:00 -0800 > From: Anna Rosen <rosen(a)ucolick.org> > To: yt-users(a)lists.spacepope.org > Subject: [yt-users] Orion Derived Fields > Message-ID: <64BC5460-361B-441A-A676-CE433376AF3B(a)ucolick.org> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > I am unable to access the derived fields written for Orion such as temperature, pressure, etc. > The definitions are these fields are located here: yt-x86_64/src/yt-hg/yt/frontends/orion/fields.py > > This is the error that I get if I try to access temperature: > > In [14]: mi,ma= dd.quantities["Extrema"]("Temperature")[0] > --------------------------------------------------------------------------- > KeyError Traceback (most recent call last) > <ipython-input-14-c8df716340ab> in <module>() > ----> 1 mi,ma= dd.quantities["Extrema"]("Temperature")[0] > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc in __call__(self, *args, **kwargs) > 90 self._data_source.pf.h.io) > 91 if lazy_reader and not self.force_unlazy: > ---> 92 return self._call_func_lazy(args, kwargs) > 93 else: > 94 return self._call_func_unlazy(args, kwargs) > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc in _call_func_lazy(self, args, kwargs) > 97 self.retvals = [ [] for i in range(self.n_ret)] > 98 for gi,g in enumerate(self._get_grids()): > ---> 99 rv = self.func(GridChildMaskWrapper(g, self._data_source), *args, **kwargs) > 100 if not iterable(rv): rv = (rv,) > 101 for i in range(self.n_ret): self.retvals[i].append(rv[i]) > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc in _Extrema(data, fields, non_zero, filter) > 586 mins, maxs = [], [] > 587 for field in fields: > --> 588 if data[field].size < 1: > 589 mins.append(1e90) > 590 maxs.append(-1e90) > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc in __getitem__(self, item) > 58 def __getitem__(self, item): > 59 if item not in self.local_cache: > ---> 60 data = self.data_source._get_data_from_grid(self.grid, item) > 61 self.local_cache[item] = data > 62 return self.local_cache[item] > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in save_state(self, grid, field, *args, **kwargs) > 89 old_keys = grid.field_data.keys() > 90 grid.field_parameters = self.field_parameters > ---> 91 tr = func(self, grid, field, *args, **kwargs) > 92 grid.field_parameters = old_params > 93 grid.field_data = YTFieldData( [(k, grid.field_data[k]) for k in old_keys] ) > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in _get_data_from_grid(self, grid, field) > 2555 return na.array([f[i,:][pointI] for i in range(3)]) > 2556 else: > -> 2557 tr = grid[field] > 2558 if tr.size == 1: # dx, dy, dz, cellvolume > 2559 tr = tr * na.ones(grid.ActiveDimensions, dtype='float64') > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in __getitem__(self, key) > 155 """ > 156 if not self.field_data.has_key(key): > --> 157 self.get_data(key) > 158 return self.field_data[key] > 159 > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in get_data(self, field, convert) > 198 else: raise > 199 else: > --> 200 self._generate_field(field) > 201 return self.field_data[field] > 202 > > /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in _generate_field(self, field) > 145 self[field] = self.pf.field_info[field](self) > 146 else: # Can't find the field, try as it might > --> 147 raise exceptions.KeyError(field) > 148 > 149 def has_key(self, key): > > KeyError: 'Temperature' > > Thanks! > > Anna Rosen > Graduate Student > UCSC, Astronomy & Astrophysics > rosen(a)ucolick.org > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 12 Nov 2012 18:30:14 -0800 > From: Andrew Myers <atmyers(a)berkeley.edu> > To: Discussion of the yt analysis package > <yt-users(a)lists.spacepope.org> > Subject: Re: [yt-users] Orion Derived Fields > Message-ID: > <CAB7F9=PN4DL9NfHnj0gBaUBdBkewVGhx7+_g1o5ewwn7Mm+TXg(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Anna, > > Check out this<https://bitbucket.org/atmyers/yt/changeset/53fa42c3dbc9c0228203900a1b1a169e…>changeset, > which I think fixes the problem. I'm not 100% sure that I > understand the distinction between "fallback" and "known" fields, but I can > confirm that with those changes all the basic orion fields work. > > -Andrew > > On Mon, Nov 12, 2012 at 4:04 PM, Anna Rosen <rosen(a)ucolick.org> wrote: > >> Hi all, >> >> I am unable to access the derived fields written for Orion such as >> temperature, pressure, etc. >> The definitions are these fields are located here: >> yt-x86_64/src/yt-hg/yt/frontends/orion/fields.py >> >> This is the error that I get if I try to access temperature: >> >> In [14]: mi,ma= dd.quantities["Extrema"]("Temperature")[0] >> --------------------------------------------------------------------------- >> KeyError Traceback (most recent call last) >> <ipython-input-14-c8df716340ab> in <module>() >> ----> 1 mi,ma= dd.quantities["Extrema"]("Temperature")[0] >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc >> in __call__(self, *args, **kwargs) >> 90 self._data_source.pf.h.io) >> 91 if lazy_reader and not self.force_unlazy: >> ---> 92 return self._call_func_lazy(args, kwargs) >> 93 else: >> 94 return self._call_func_unlazy(args, kwargs) >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc >> in _call_func_lazy(self, args, kwargs) >> 97 self.retvals = [ [] for i in range(self.n_ret)] >> 98 for gi,g in enumerate(self._get_grids()): >> ---> 99 rv = self.func(GridChildMaskWrapper(g, >> self._data_source), *args, **kwargs) >> 100 if not iterable(rv): rv = (rv,) >> 101 for i in range(self.n_ret): >> self.retvals[i].append(rv[i]) >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc >> in _Extrema(data, fields, non_zero, filter) >> 586 mins, maxs = [], [] >> 587 for field in fields: >> --> 588 if data[field].size < 1: >> 589 mins.append(1e90) >> 590 maxs.append(-1e90) >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.pyc >> in __getitem__(self, item) >> 58 def __getitem__(self, item): >> 59 if item not in self.local_cache: >> ---> 60 data = self.data_source._get_data_from_grid(self.grid, >> item) >> 61 self.local_cache[item] = data >> 62 return self.local_cache[item] >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in >> save_state(self, grid, field, *args, **kwargs) >> 89 old_keys = grid.field_data.keys() >> 90 grid.field_parameters = self.field_parameters >> ---> 91 tr = func(self, grid, field, *args, **kwargs) >> 92 grid.field_parameters = old_params >> 93 grid.field_data = YTFieldData( [(k, grid.field_data[k]) >> for k in old_keys] ) >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in >> _get_data_from_grid(self, grid, field) >> 2555 return na.array([f[i,:][pointI] for i in range(3)]) >> 2556 else: >> -> 2557 tr = grid[field] >> 2558 if tr.size == 1: # dx, dy, dz, cellvolume >> 2559 tr = tr * na.ones(grid.ActiveDimensions, >> dtype='float64') >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in >> __getitem__(self, key) >> 155 """ >> 156 if not self.field_data.has_key(key): >> --> 157 self.get_data(key) >> 158 return self.field_data[key] >> 159 >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in >> get_data(self, field, convert) >> 198 else: raise >> 199 else: >> --> 200 self._generate_field(field) >> 201 return self.field_data[field] >> 202 >> >> /home1/arosen2/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in >> _generate_field(self, field) >> 145 self[field] = self.pf.field_info[field](self) >> 146 else: # Can't find the field, try as it might >> --> 147 raise exceptions.KeyError(field) >> 148 >> 149 def has_key(self, key): >> >> KeyError: 'Temperature' >> >> Thanks! >> >> Anna Rosen >> Graduate Student >> UCSC, Astronomy & Astrophysics >> rosen(a)ucolick.org >> >> >> >> _______________________________________________ >> yt-users mailing list >> yt-users(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >

3 2

error on hierarchy access.
by david collins 21 Nov '12

21 Nov '12

Is this behavior familiar to anyone? I've done this with a fresh build and one from a few months ago. The set was generated with the latest build of enzo. With a set generated from an earlier enzo build, I can read the set just fine. Thanks! d. >>> from yt.mods import * >>> pf = load('/Users/dccollins/Enzo/unstable/run/GravitySolver/GravityTest/./DD0000/data0000') >>> pf.h Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/dccollins/local2/src/yt-hg/yt/data_objects/static_output.py", line 189, in hierarchy self, data_style=self.data_style) File "/Users/dccollins/local2/src/yt-hg/yt/frontends/enzo/data_structures.py", line 218, in __init__ AMRHierarchy.__init__(self, pf, data_style) File "/Users/dccollins/local2/src/yt-hg/yt/data_objects/hierarchy.py", line 62, in __init__ self._count_grids() File "/Users/dccollins/local2/src/yt-hg/yt/frontends/enzo/data_structures.py", line 240, in _count_grids self._guess_data_style(self.pf.dimensionality, test_grid, test_grid_id) File "/Users/dccollins/local2/src/yt-hg/yt/frontends/enzo/data_structures.py", line 243, in _guess_data_style if test_grid[0] != os.path.sep: TypeError: 'NoneType' object is not subscriptable -- Sent from my computer.

3 2

OpenSuse Install Troubles
by Nicholas Earl 20 Nov '12

20 Nov '12

Hey all, I've been trying to stick yt on an opensuse box, and I've run into a kind of funky error when it attempts to install mercurial-2.2.2. I just wanted to see if perhaps anyone has hit this wall before? user_base = getuserbase() # this will also set USER_BASE File "/home/nearl/yt-x86_64/lib/python2.7/site.py", line 243, in getuserbase USER_BASE = get_config_var('userbase') File "/home/nearl/yt-x86_64/lib/python2.7/sysconfig.py", line 520, in get_config_var return get_config_vars().get(name) File "/home/nearl/yt-x86_64/lib/python2.7/sysconfig.py", line 419, in get_config_vars _init_posix(_CONFIG_VARS) File "/home/nearl/yt-x86_64/lib/python2.7/sysconfig.py", line 287, in _init_posix raise IOError(msg) IOError: invalid Python installation: unable to open /home/nearl/yt-x86_64/lib/python2.7/config/Makefile (No such file or directory) The directory /config does not exist. I've attempted to install the python-devel package, along with the python-setuptools-devel package, but they didn't seem to help at all. I haven't worked with opensuse before, so it's quite possible that this may be a platform-dependent issue. Any suggestions would be greatly appreciated! Nick

2 1

Fwd: cylindrical coordinates in Athena
by Kaitlin Kratter 16 Nov '12

16 Nov '12

Hi, I gather that cylindrical geometries aren't supported. Is it possible to force yt to read in cylindrical coordinates as though they were cartesian? When I try to load an athena vtk in cylindrical, I get: In [32]: pf = load("cyl_disk.0001.vtk") yt : [INFO ] 2012-11-15 15:31:26,443 Temporarily setting domain_right_edge = -domain_left_edge. This will be corrected automatically if it is not the case. yt : [INFO ] 2012-11-15 15:31:26,445 Parameters: current_time = 0.001080635 yt : [INFO ] 2012-11-15 15:31:26,445 Parameters: domain_dimensions = [ -37 128 -2147483648] yt : [INFO ] 2012-11-15 15:31:26,445 Parameters: domain_left_edge = [ 1. -1.570796 0. ] yt : [INFO ] 2012-11-15 15:31:26,445 Parameters: domain_right_edge = [-1. 1.570796 -0. ] yt : [INFO ] 2012-11-15 15:31:26,445 Parameters: cosmological_simulation = 0.0 This is a 256 by 128 grid, and the dimensions should be -pi/2, pi/2 and 1, 15. Thanks, Kaitlin

4 15

unsubscribe
by Wim Zwitser 16 Nov '12

16 Nov '12

1 0

Runtime Error: unitsystem cgs unrecognized
by Patrick Rieser 15 Nov '12

15 Nov '12

Hey all! When I try to call my own added field magB I get a runtime error saying that the cgs unitsystem is unrecognized. When I insert pf["unitsystem"] == "cgs" directly before the call where the traceback starts, it returns true. Best wishes, Patrick I add the field with: def _magB(field,data): return (na.sqrt(data["Bx"]**2 + data["By"]**2 + data["Bz"]**2)) add_field("magB", function=_magB, units=r"\rm{Gauss}") and then call: rad_profile.add_fields("magB") Traceback: File "rad_profile_magb.py", line 100, in <module> rad_profile.add_fields("magB") File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py", line 170, in add_fields self._unlazy_add_fields(fields, weight, accumulation) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py", line 151, in _unlazy_add_fields accumulation, self._args, check_cut = False) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py", line 55, in save_state tr = func(*args, **kwargs) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py", line 264, in _bin_field source_data = self._get_field(source, field, check_cut) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py", line 204, in _get_field data.append(source[field][pointI].ravel().astype('float64')) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 328, in __getitem__ self.get_data(key) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 2593, in get_data if self._generate_field(field): File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 358, in _generate_field self[field] = self.pf.field_info[field](self) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py", line 378, in __call__ dd = self._function(self, data) File "/home/patrick/Auswertung/yt-bit/Plot/common_fields.py", line 7, in _magB return (na.sqrt(data["Bx"]**2 + data["By"]**2 + data["Bz"]**2)) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 328, in __getitem__ self.get_data(key) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 2593, in get_data if self._generate_field(field): File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 358, in _generate_field self[field] = self.pf.field_info[field](self) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py", line 378, in __call__ dd = self._function(self, data) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/frontends/flash/fields.py", line 357, in _Bx factor = GetMagRescalingFactor(data.pf) File "/home/patrick/Programme/yt-x86_64/src/yt-hg/yt/frontends/flash/fields.py", line 353, in GetMagRescalingFactor "value %s is unrecognized" % pf['unitsystem']) RuntimeError: Runtime parameter unitsystem withvalue cgs is unrecognized

3 6

Strange Behaviour in ProjectionPlot
by Patrick Rieser 13 Nov '12

13 Nov '12

Hey all, So I still get some strange behaviour with the ProjectionPlot. If I use the projection.set_width() with the clumps callback method I get the real image shrinked inside the the plot window. Strange thing is, that it grows with each step! Here is a demonstration how it looks (you have to look closely as it doesn't grow that much each step): http://www.flickr.com/photos/87912862@N05/sets/72157631990474435/ If I don't use the set_width() then the image itself looks fine, but the scale on the axis grows with each step. So it seems to be the same error than with fixed width. Best wishes, Patrick Here is the code that I am using: # ID is just a list of tuples with clumps/their position in an array # sim_files and clump_files is a list containing the filenames # get_myclump() simply returns a specific clump for j, series in enumerate(ID): for i in series: pf = load(sim_files[i[0]]) myclump = get_myclump(clump_files[i[0]], i[1]) pc = ProjectionPlot(pf, axis, my_field, center = pf.domain_center, weight_field = my_wfield) pc.set_width(28, "mpc") pc.annotate_text([0.0,1.05], "Clump %s" % j) if redshift: pc.annotate_text([0.917,1.05], "z = %0.4f" % pf.current_redshift) if grid: pc.annotate_grids() if fix_scale: pc.set_zlim(my_field,boundaries[0],boundaries[1]) pc.set_cmap("Density", "idl01") pc.annotate_clumps(myclump) pc.save('%s/Clump_%s_File_%s_Nr_%s_%s_Projection.png' % (myBASEDIR, j, i[0], i[1], axis))

4 12

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

yt-users November 2012