Mailman 3 November 2015 - yt-dev

PR Triage Hangout
by Hilary Egan 18 Dec '15

18 Dec '15

Hi all, Here's the link to tomorrows PR triage hangout. https://plus.google.com/events/c2nl75lj8g8e4ohl93of147d2og?ghf=3049771 -Hilary -- Hilary Egan Astrophysical and Planetary Science Department University of Colorado Boulder

3 5

Thoughts on the future of units and fields
by Matthew Turk 26 Nov '15

26 Nov '15

Hi all, I promised an email about this last Friday, and I'm now finally getting around to it. Hooray? One common problem that comes up pretty often is the issue of how fields on-disk are represented, how the units and whatnot get passed into the frontends, and then how to change this. As an example, it can be really quite tricky to tell yt that, no, hey, turns out, *this* version of the data has *different* units than the *other* version, or something. We special case these in the frontends in almost all cases -- which requires touching the yt source code, rather than something that can be passed in. I'd like to propose a handful of things, which may or may not be reasonable. * fields.py currently uses tuples of values hanging off a class definition, which are rather undocumented and also oddly mixed in mutability and immutability. I'm still trying to think through the best way to improve this. But, the simplest problem that *needs* to be fixed is that this is fragile to changing the arguments. We can't add new attributes without changing everything. Same for getting rid of arguments. * to_cgs should instead be to_natural in almost all cases. Setting the "natural" units of a dataset should be possible. This would enable doing things like code-as-natural, mks-as-natural, etc. I *think* it is straightforward, having looked at the code, but it's also slightly out of my depth in the unit system. * We should be able to standardize unit *override*. We should, at the very least, be able to pass in a dict that maps field tuples to on-disk units, which would override whatever is in fields.py. * Having a method of dynamically defining code_something units would be very useful; this has shown up in odd ways with things like particle units in octree codes where the code_length is differently defined for different fields. Having a dynamic code_* definition would ease this, rather than mandating that there are N code_ fields, of names blah blah blah. OK, there are my thoughts. Longer term thoughts could be to change our field definitions to all be sympy expressions, which could be simplified, but that's for another day. -Matt

1 0

Re: [yt-dev] Progress on Get_Vertex_Centered_Data for Octree data
by Tomer Nussbaum 25 Nov '15

25 Nov '15

Hey Mark, I have done some progress on get_vertex_centred_data, with simple extrapolation, we can get: https://sketchfab.com/models/d267102434274bdbb5f75f5b9ef27b44. As you can see, this solution does not work so well, so now Matthew Turk and I are working on changing the parsing of the octTree to include ghostzones. It's great to have another companion to this part of the code. do you have a Slack account? lets talk there. (I am @tussbaum) Matt, anything to add? Cheers, Tomer On Wed, Nov 25, 2015 at 2:24 PM, Mark Richardson < Mark.Richardson(a)physics.ox.ac.uk> wrote: > Hello, > I see that the fact that Octree doesn't currently work with > get_vertex_centred_data had some interest recently. Tomer, have you made > much progress on this since early November? I'm also very interested in > getting this to work (I use Ramses), so if you'd like, I'd enjoy coming on > board and helping in what ways I can. > > To start, is there a fork I can follow on the bitbucket? > > Cheers, > -Mark > > -- > > Mark Richardson > Beecroft Postdoctoral Fellow, Department of Physics > Denys Wilkinson Building - 555F > University of Oxford > Mark.Richardson(a)physics.ox.ac.uk > +44 1865 280793 >

2 1

Issue #1147: Derived quantities `max_location` and `min_location` not returning correct index values (yt_analysis/yt)
by Cameron Hummels 24 Nov '15

24 Nov '15

New issue 1147: Derived quantities `max_location` and `min_location` not returning correct index values https://bitbucket.org/yt_analysis/yt/issues/1147/derived-quantities-max_loc… Cameron Hummels: Something is going awry in the `max_location` and `min_location` derived quantities such that they return an incorrect index for where the extrema occur. Here's an example script. I tried correcting the code, but I got caught up in the chunk processing for derived quantities. ``` #!python import yt import numpy as np ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') ad = ds.all_data() val, index, x, y, z = ad.quantities.max_location('density') print val == ad['density'][int(index)] # false val2 = ad['density'].max() index2 = np.argmax(ad['density']) print val2 == ad['density'][index2] # true print val == val2 # true print index == index2 # false # Thus, something is going awry in the max_location (and the min_location) # derived quantities where it calculates the index values for the extrema ```

3 3

PR Triage Hangout
by Hilary Egan 23 Nov '15

23 Nov '15

Hi all, Here's the link for next week's PR triage hangout and a reminder that they will now be Mondays at 2pm EST! https://plus.google.com/b/107728486871834552760/events/car4cot30l8gu65a3b6e… -- Hilary Egan Astrophysical and Planetary Science Department University of Colorado Boulder

3 8

Issue #1146: Octree construction on some SPH datasets revealing large swath of simulation space with zero density (yt_analysis/yt)
by Cameron Hummels 22 Nov '15

22 Nov '15

New issue 1146: Octree construction on some SPH datasets revealing large swath of simulation space with zero density https://bitbucket.org/yt_analysis/yt/issues/1146/octree-construction-on-som… Cameron Hummels: Following the discussion in PR #1880, we identified that the octree construction was not behaving correctly for some SPH datasets. Rather than having full coverage in mesh fields across the simulation volume, regions of no gas particles have their mesh fields deposited as zero (i.e. zero density, zero temperature, etc.). Formally, this should never happen, and it can lead to a lot of unpredictable behavior later in processing the data. For more information on this problem and how to reproduce it, see Pull Request #1880.

1 0

Issue #1145: ParticlePlot docs have several empty images being rendered (yt_analysis/yt)
by Cameron Hummels 22 Nov '15

22 Nov '15

New issue 1145: ParticlePlot docs have several empty images being rendered https://bitbucket.org/yt_analysis/yt/issues/1145/particleplot-docs-have-sev… Cameron Hummels: The [ParticlePlot docs](http://yt-project.org/docs/dev/visualizing/plots.html#particle-plots) have several images that are clearly not plotting what they are supposed to be plotting, so it looks like some of the infrastructure got changed and broke something. Notably, the [last stable version of the docs](http://yt-project.org/docs/3.2/visualizing/plots.html#particle-plots), version 3.2, does not suffer from these problems.

1 0

Adding a CONTRIBUTING file
by Nathan Goldbaum 21 Nov '15

21 Nov '15

Hi all, I think a piece of low-hanging fruit to make the contributing process clearer would be to add a CONTRIBUTING file to the main yt repository. I think the text of this file mostly exists already in this document in the docs: http://yt-project.org/doc/developing/developing.html One thing I could do is extract the text of that document from the docs sources and simply add it to the root of the repository like I've done with the coding style guide in my open style PR. This way it's still in the docs build (since it will be included using a sphinx include statement) but the instructions will be closer to the code location in the root of the repository, increasing discoverability for new contributors who are not aware of the developer guide in the docs. This CONTRIBUTING file could also subsume the coding_styleguide.txt file. This file could also summarize, discuss, and highlight the code of conduct: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0023.html Do others think this is a good idea? Are there other things that should be in a CONTRIBUTING file. Maybe instead of copy/pasting the content of the developing.rst file in the docs, it could just link to the developer guide, and the discussion of the code of conduct and any other new things we'd like to add could be added there. Thanks for your advice, Nathan

2 4

Fwd: [IPython-User] [JOB] Project Jupyter is hiring two postdoctoral fellows @ UC Berkeley.
by Matthew Turk 20 Nov '15

20 Nov '15

---------- Forwarded message ---------- From: Fernando Perez <fperez.net(a)gmail.com> Date: Thu, Nov 19, 2015 at 3:42 PM Subject: [IPython-User] [JOB] Project Jupyter is hiring two postdoctoral fellows @ UC Berkeley. To: jupyter(a)googlegroups.com, IPython Development list <ipython-dev(a)scipy.org>, IPython User list <ipython-user(a)scipy.org>, SciPy Developers List <scipy-dev(a)scipy.org> Hi all, We are delighted to announce today that Project Jupyter/IPython has two postdoctoral fellowships open at UC Berkeley, open immediately. Interested candidates can apply here: https://aprecruit.berkeley.edu/apply/JPF00899 We hope to find candidates who will work on a number of challenging questions over the next few years, as described in our grant proposal here: http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives… Interested candidates should carefully read that proposal before applying to familiarize themselves with the full scope of the questions we intend to tackle. We'd like to thank the support of the Helmsley Trust, the Gordon and Betty Moore Foundation and the Alfred P. Sloan Foundation. Cheers, Brian Granger and Fernando Perez. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail _______________________________________________ IPython-User mailing list IPython-User(a)scipy.org https://mail.scipy.org/mailman/listinfo/ipython-user

1 0

Issue #1144: numpy and typecasting for in place operations (yt_analysis/yt)
by Giovi Pelle 19 Nov '15

19 Nov '15

New issue 1144: numpy and typecasting for in place operations https://bitbucket.org/yt_analysis/yt/issues/1144/numpy-and-typecasting-for-… Giovi Pelle: Python 3.4 Numpy 1.10.1 The example for loading [generic array data](http://yt-project.org/doc/examining/generic_array_data.html) fails with the following traceback: ```Python -------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-17-91acb99a6f75> in <module>() 1 data = dict(density = (arr, "g/cm**3")) 2 bbox = np.array([[-1.5, 1.5], [-1.5, 1.5], [-1.5, 1.5]]) ----> 3 ds = yt.load_uniform_grid(data, arr.shape, length_unit="Mpc", bbox=bbox, nprocs=64) /home/giovi/anaconda3/lib/python3.4/site-packages/yt/frontends/stream/data_structures.py in load_uniform_grid(data, domain_dimensions, length_unit, bbox, nprocs, sim_time, mass_unit, time_unit, velocity_unit, magnetic_unit, periodicity, geometry) 638 new_data = {} 639 for key in data.keys(): --> 640 psize = get_psize(np.array(data[key].shape), nprocs) 641 grid_left_edges, grid_right_edges, shapes, slices = \ 642 decompose_array(data[key].shape, psize, bbox) /home/giovi/anaconda3/lib/python3.4/site-packages/yt/utilities/decompose.py in get_psize(n_d, pieces) 93 i = fac[nfac, 1] - i 94 j = fac[nfac, 1] - (i + k) ---> 95 ldom *= fac[nfac, 0] ** np.array([i, j, k]) 96 97 quality = evaluate_domain_decomposition(n_d, pieces, ldom) TypeError: Cannot cast ufunc multiply output from dtype('float64') to dtype('int64') with casting rule 'same_kind' ``` I guess it can be attributed to the new numpy typecasting rule for in-place operation. Probably it is a simple fix for you. Best Giovanni Responsible: yt_analysis

1 0