Mailman 3 April 2014 - yt-dev

Issue #828: Clump finder raises a NotImplementedError (yt_analysis/yt)
by Nathan Goldbaum 06 Apr '14

06 Apr '14

New issue 828: Clump finder raises a NotImplementedError https://bitbucket.org/yt_analysis/yt/issue/828/clump-finder-raises-a-notimp… Nathan Goldbaum: This example script comes from the docs: ``` #!python from yt.mods import * from yt.analysis_modules.level_sets.api import * pf = load("IsolatedGalaxy/galaxy0030/galaxy0030") data_source = pf.disk([0.5, 0.5, 0.5], [0., 0., 1.], (8., 'kpc'), (1., 'kpc')) c_min = 10**np.floor(np.log10(data_source['density']).min() ) c_max = 10**np.floor(np.log10(data_source['density']).max()+1) function = 'self.data[\'Density\'].size > 20' master_clump = Clump(data_source, None, 'density', function=function) find_clumps(master_clump, c_min, c_max, 2.0) leaf_clumps = get_lowest_clumps(master_clump) prj = ProjectionPlot(pf, 2, 'density', center='c', width=(20,'kpc')) prj.annotate_clumps(leaf_clumps) prj.save('clumps') ``` It currently fails with the following traceback: ``` Traceback (most recent call last): File "temp.py", line 13, in <module> find_clumps(master_clump, c_min, c_max, 2.0) File "/Users/goldbaum/Documents/yt-hg/yt/analysis_modules/level_sets/clump_handling.py", line 171, in find_clumps clump.find_children(min_val) File "/Users/goldbaum/Documents/yt-hg/yt/analysis_modules/level_sets/clump_handling.py", line 110, in find_children nj, cids = identify_contours(self.data, self.field, min_val, max_val) File "/Users/goldbaum/Documents/yt-hg/yt/analysis_modules/level_sets/contour_finder.py", line 36, in identify_contours for (g, node, (sl, dims, gi)) in data_source.tiles.slice_traverse(): File "/Users/goldbaum/Documents/yt-hg/yt/utilities/amr_kdtree/amr_kdtree.py", line 189, in slice_traverse raise NotImplementedError NotImplementedError ```

1 0

Proposal: merge 'experimental' bookmark into the 'development' bookmark
by Nathan Goldbaum 06 Apr '14

06 Apr '14

Hi all, This came up during the google hangout this morning and I think it's a good idea. Right now there are four heads and three named branches in the yt_analysis/yt mercurial repository: - "stable" This corresponds to the 2.6.2 stable release. - "yt" This corresponds to the 2.7dev branch - "development" This is on the yt-3.0 named branch, but before the unitrefactor and field refactor were merged in. - "experimental" This is also on the yt-3.0 named branch, and incldues unitrefactor, field refactor, and many other changes added since the development workshop at UCSC. I see a good reason to retain the "yt" development branch - there have several pull requests into it and many of our users are still using it for day-to-day work. I don't see a good reason to keep the distinction between "development" and "experimental". There have been no pull requests into the "development" bookmark. There are also known bugs with respect to particle field detection on the "development" bookmark. We wanted to keep the "development" bookmark as a way to easily update to a yt-3.0 release from before the time when unitrefactor and the field refactor were merged in. I think that keeping a seperate head in the repository for this purpose is unnecessary - we could just have a named tag. For example, we could call it yt-3.0a5 and point it at the current development bookmark changeset (0d705d2ae8eb). Benefits to doing this: We would only have three heads in the main repo, each on a different named branch. This will make it easier to work with bitbucket, which has a UI optimized for named branches rather than bookmarks. We will onboard more users to the new codebase, which is the way forward and represents the code that will actually be released for the final 3.0 release. Possible issues: The "bleeding edge" install script will build a version of yt including all the new features. Since documentation is still not up to snuff, there might be confusion due to innacurate or incomplete documentation. I'd love to hear feedback about this - particularly if there are any strong objections. -Nathan

7 7

Why are particle masses returned in code units?
by Nathan Goldbaum 05 Apr '14

05 Apr '14

Hi all, Does anyone know why particle fields are turned in code units? For example: >>> import yt >>> ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') >>> ad = ds.all_data() >>> print ad['all', 'particle_mass'] [ 5.24322377e-06 5.24322377e-06 5.24423058e-06 ..., 2.51688903e-06 2.52040900e-06 2.52345330e-06] code_mass >>> print ad['all', 'particle_position_x'] [ 0.50070677 0.50118382 0.50118984 ..., 0.49867166 0.49857796 0.49865383] code_length For fluid fields, we have aliases for on-disk fields that get returned in code units, but the 'standard' yt fields are all in CGS by default: >>> print ad['gas', 'density'] [ 4.92775113e-31 4.94005233e-31 4.93824694e-31 ..., 1.12879234e-25 1.59561490e-25 1.09824903e-24] g/cm**3 >>> print ad['enzo', 'Density'] [ 1.78469285e-01 1.78914800e-01 1.78849414e-01 ..., 4.08816836e+04 5.77886836e+04 3.97754906e+05] code_mass/code_length**3 I guess we don't really have a distinction like that on the particle side of things. I tend to think that it should be easier to access particle fields in CGS units and that we should default to having 'standard' particle fields in CGS, just like the fluid fields. That said, looking at YTEP-0003, it seems we focused mostly on fluid fields and didn't think very hard about how particle fields should work. For example, 'particle_mass' is never mentioned. I realize that completely refactoring the particle fields will be a fair bit of work so we may not be able to change things before yt 3.0 is released, but I think this should be part of the discussion as we develop a more consistent set of rules for how yt fields should work, including multifluid, multiparticle, and multispecies datasets. I'd love to hear other's thoughts on this. -Nathan

3 7

Issue #827: Enzo particle fields work differently than the other frontends (yt_analysis/yt)
by Nathan Goldbaum 05 Apr '14

05 Apr '14

New issue 827: Enzo particle fields work differently than the other frontends https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-di… Nathan Goldbaum: Since we use enzo field names as the 'standard' yt fields the Enzo frontend is setup such that it doesn't define any aliases. This introduces an asymmetry compared to the other frontends, since alias fields are always in CGS. Take as an example the following script: ``` #!python import yt fns = [ 'sizmbhloz-clref04SNth-rs9_a0.9011/sizmbhloz-clref04SNth-rs9_a0.9011.art', 'IsolatedGalaxy/galaxy0030/galaxy0030' ] for fn in fns: ds = yt.load(fn) ad = ds.all_data() print ds print ad['particle_mass'] print ad['particle_position_x'] print "-------------------------" ``` On the current experimental bookmark, this prints: ``` sizmbhloz-clref04SNth-rs9_a0.9011.art [ 2.60330963e+40 2.60330963e+40 2.60330963e+40 ..., 2.60330963e+40 2.60330963e+40 8.91022090e+38] g [ 3.84477674e+24 3.87559159e+24 3.89111431e+24 ..., 4.03783894e+24 4.12904314e+24 4.44574239e+24] cm ------------------------- galaxy0030 [ 5.24322377e-06 5.24322377e-06 5.24423058e-06 ..., 2.51688903e-06 2.52040900e-06 2.52345330e-06] code_mass [ 0.50070677 0.50118382 0.50118984 ..., 0.49867166 0.49857796 0.49865383] code_length ------------------------- ``` The net effect is that for Enzo we can't access particle fields in CGS and only see fields in code units.

1 0

bug in SFRD calculation
by Geoffrey So 04 Apr '14

04 Apr '14

There seems to be a bug in the star formation rate density calculation routine. The volume is only the real 'proper volume' at the current redshift and not at any other redshifts, because it uses the current redshift in the calculation of proper volume in all redshifts. #--------------------------------- from yt.mods import * from yt.analysis_modules.star_analysis.api import * import pylab pf=load('HD1200/HD1200') dd=pf.h.all_data() sfr = StarFormationRate(pf, data_source=dd, bins=10) sfr.write_out(name="StarFormationRate.out") time, lookback, z, Msolyr, MsolyrMpc3, Msol, cumMsol=na.loadtxt('StarFormationRate.out',usecols=(0,1,2,3,4,5,6),skiprows=2,unpack=True) cMpc3,=pylab.plot(z,Msolyr/(pf['CosmologyComovingBoxSize']/pf['CosmologyHubbleConstantNow'])**3) currentz,=pylab.plot(z,MsolyrMpc3/(1+pf.current_redshift)**3+1e-5) Expect,=pylab.plot(z,MsolyrMpc3/(1+z)**3) pylab.legend([cMpc3,currentz,Expect], ['[s$^{-1}$cMpc$^{-3}$]', 'use only current z to fit', 'Expected to fit']) pylab.savefig('SFRD.eps') #--------------------------------- in the file: yt/analysis_modules/star_analysis/sfr_spectrum.py line 151: self.Msol_yr_vol.append(self.mass_bins[i] / \ (self.time_bins_dt[i] * tc / YEAR) / vol) The vol is a fixed number instead of varying by the redshift, even though the numerator in solar masses per year is from different redshifts. So I think a couple lines above it should create an empty array of vol vol = [] In the loop for i, time... calculate the right volume vol[i] Then instead of dividing by the constant vol, divide by vol[i] corresponding to the right redshift. self.Msol_yr_vol.append(self.mass_bins[i] / \ (self.time_bins_dt[i] * tc / YEAR) / vol[i]) From G.S.

3 4

Issue #826: FRB unit error when using Tipsy datasets (yt_analysis/yt)
by smbenincasa 04 Apr '14

04 Apr '14

New issue 826: FRB unit error when using Tipsy datasets https://bitbucket.org/yt_analysis/yt/issue/826/frb-unit-error-when-using-ti… smbenincasa: There's an issue with units when you make an FRB from a Tipsy dataset (Ben Keller suggested I post). Here's the error /1/home/benincsm/yt/yt-3.0-test/yt/yt/units/yt_array.py(776)__array_wrap__() 775 else: --> 776 raise RuntimeError("Operation is not defined.") 777 if unit is None: I've attached the script (it's just taken from the cookbook) Thanks in advance!

1 0

Hangout on Friday
by Matthew Turk 04 Apr '14

04 Apr '14

Hi all, This Friday I'm going to have a hangout on G+ just as a space to catch up on things. 11AM eastern, and I will commit to being there for two hours to give West Coasters some time to join in that isn't too early. Please stop by if you have questions, want to chat development, want to do some code sprinting, or are running into issues with anything. It would also be a good opportunity to go over the trello board and update all the cards. https://plus.google.com/events/c72bbg1u0kmbgj20cfn0gclbhhs -Matt

1 1

Should we remove plot collection before 3.0?
by Matthew Turk 02 Apr '14

02 Apr '14

Hi all, I'm inclined to remove plot collection before yt 3.0 is released. PhasePlot and ProfilePlot both work in 2.6, and we've actually seen quite a bit of migration to them. If there's enough support, I'll bring this to a YTEP and we can hash it out there, but before I went to that point I figured I'd look for a handful of +1's here. -Matt

7 10

Re: [yt-dev] [yt-users] Fwd: [IPython-dev] [ANNOUNCE] IPython 2.0.0
by Matthew Turk 02 Apr '14

02 Apr '14

(Bringing back to yt-dev) I think we should come up with a timescale for upgrading the dependency stack. I'd like to propose that we upgrade the script for the 3.0 release to include IPython 2.0.0, and that the widgets Ben, Nathan and Sam have been working on make their way in to the repo. -Matt On Wed, Apr 2, 2014 at 2:05 AM, Nathan Goldbaum <nathan12343(a)gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: MinRK <benjaminrk(a)gmail.com> > Date: Tue, Apr 1, 2014 at 10:57 PM > Subject: [IPython-dev] [ANNOUNCE] IPython 2.0.0 > To: IPython Development list <ipython-dev(a)scipy.org> > Cc: ipython user list <IPython-User(a)scipy.org> > > > While April 1 may be a very loose definition of winter, IPython 2.0 is > actually [out](https://pypi.python.org/pypi/ipython)! > > I promise this is not an April Fool's joke, but if you don't believe me just > > pip install --upgrade ipython > > to find out. > > See [what's new](http://ipython.org/ipython-doc/2/whatsnew/version2.0.html) > for more details, but the highlights are: > > - interactive widgets for the notebook > - directory navigation in the notebook dashboard > - persistent URLs for notebooks > - a new modal user interface in the notebook > - a security model for notebooks > > You can check out the [example > notebooks](http://nbviewer.ipython.org/github/ipython/ipython/blob/master/e… > on nbviewer, or download them and try things out yourself. > > This is the first IPython release with wheels (one for py2, one for py3, for > now), so please give those a test if you can. These will be installed by > default for anyone using current pip (1.5). > > We plan to have 2.0.1 within a month based on initial feedback, so bring on > the bug reports! > > Thanks for all your support, we have a great time working on this. > > -IPython HQ > > _______________________________________________ > IPython-dev mailing list > IPython-dev(a)scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >

1 0

Issue #825: Creating an all_data object does not generate the field_info object. (yt_analysis/yt)
by Nathan Goldbaum 01 Apr '14

01 Apr '14

New issue 825: Creating an all_data object does not generate the field_info object. https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-… Nathan Goldbaum: The following script and traceback illustrates the issue: ``` #!python import yt ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') ad = ds.all_data() print ad.quantities.total_mass() ``` ``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info' ``` Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.

4 7