Mailman 3 October 2014 - yt-dev

Issue #918: Deposit fields cannot be created using ghost zones (yt_analysis/yt)
by Nathan Goldbaum 08 Oct '14

08 Oct '14

New issue 918: Deposit fields cannot be created using ghost zones https://bitbucket.org/yt_analysis/yt/issue/918/deposit-fields-cannot-be-cre… Nathan Goldbaum: After applying the following patch: ``` #!patch diff -r 7ae8714f591e yt/fields/particle_fields.py --- a/yt/fields/particle_fields.py Tue Oct 07 23:21:33 2014 -0700 +++ b/yt/fields/particle_fields.py Wed Oct 08 14:57:04 2014 -0700 @@ -121,7 +121,7 @@ registry.add_field(("deposit", "%s_cic" % ptype), function = particle_cic, - validators = [ValidateSpatial()], + validators = [ValidateSpatial(1)], display_name = "\\mathrm{%s CIC Density}" % ptype_dn, units = "g/cm**3") ``` And running this script: http://paste.yt-project.org/show/5151/ The following error will be raised: https://bpaste.net/show/1a4dbe75eb96 This is actually infinite recursion error, the incorrect error raised here is fixed in [PR 1244](https://bitbucket.org/yt_analysis/yt/pull-request/1244/remove-some-un…. h/t to @atmyers for originally discovering this error.

1 0

Particle Deposition fields and grid boundaries
by Andrew Myers 08 Oct '14

08 Oct '14

Hi Folks, I'm trying to understand how the particle deposition fields work for grid-based codes. Specifically, how does yt handle particles that are close to the grid boundaries, so that the CIC interpolation stencil involves cells on grid(s) other than the one that contains the particle position?. Like, say I did: import yt ds = yt.load(fn) g = ds.index.grids[0] print g['deposit', 'all_cic'] How does yt handle the fact that particles other than those living on "g" can contribute to the total CIC density? Does it grab a layer of "ghost particles" somehow? I can't seem to find where that happens. Sorry if I'm just missing something obvious here... Best, Andrew

3 7

Issue #917: Cloud in cell deposition doesn't do the right thing at grid boundaries (yt_analysis/yt)
by Nathan Goldbaum 07 Oct '14

07 Oct '14

New issue 917: Cloud in cell deposition doesn't do the right thing at grid boundaries https://bitbucket.org/yt_analysis/yt/issue/917/cloud-in-cell-deposition-doe… Nathan Goldbaum: See the following notebook for an example: http://nbviewer.ipython.org/gist/ngoldbaum/eb40dfe74cd58a4e16ba

1 0

on adding new frontends
by Chris Malone 07 Oct '14

07 Oct '14

All, Are there any requirements/restrictions on what types of codes should be added as new frontends in the yt repository? I ask because yesterday I wrote a frontend for a collaborator working with the Dumses code. As best I can tell, Dumses is a stripped-down version of Ramses, but without the AMR and with a completely different file format. Also, as best I can tell, only a handful of people (mainly at the CEA?) work on this code, and it is nigh-impossible to find any information on the interwebs about it. Should I fold this new frontend into the main yt repo, or just give the users of Dumses the frontend code and let them do what they will? The former might pull in a couple more users/developers, but the latter would keep us from cluttering yt/frontends. Chris

6 7

proper handling species fields
by Chris Malone 07 Oct '14

07 Oct '14

At Britton's great suggestion, let's move the discussion of what to do with species fields from BitBucket comments to here. For reference, see the discussion in the comments here [1]. Note that the current situation is outlined in YTEP-003, specifically the section on species names [2]. The main issue is that yt supports a wide range of codes, which are applicable in various domains of science and sometimes the nomenclature clashes. What is meant by 'species' is a prime example. 'Species' can mean atomic elements, ions, or nuclei (perhaps others?), and the definition of each of these should - if it is possible - be made explicit. Agreeing on the yt-internal nomenclature for this explicitness requires some discussion. [1] https://bitbucket.org/yt_analysis/yt/pull-request/1240/bugfix-fixing-nuclei… [2] http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html#molecular-and-at… Chris

4 5

Issue #915: SlicePlot fails with odd combination of width units (yt_analysis/yt)
by Chris Malone 06 Oct '14

06 Oct '14

New issue 915: SlicePlot fails with odd combination of width units https://bitbucket.org/yt_analysis/yt/issue/915/sliceplot-fails-with-odd-com… Chris Malone: For a `SlicePlot` with a user-specified `width` that has different units, the plot fails to properly render and matplotlib complains issuing warnings. See the last plot in this [notebook](http://nbviewer.ipython.org/urls/dl.dropbox.com/s/bf62wclpjduvlit… In the above notebook, `w[0]` has units of `code_length`, whereas `w[1]` has units of `Mpc`. It's not clear if all non-similar units cause an issue, or if this is pathological.

3 6

advice on derived field debugging
by Britton Smith 06 Oct '14

06 Oct '14

Hi all, There seems to be an issue accessing the nuclei density fields. These are derived fields that give the total number density of an element with names like "H_nuclei_density." At some point, these have stopped working and I am trying to debug this. To reproduce this, one can do the following: ds = yt.load("enzo_cosmology_plus/DD0046/DD0046") ad = ds.all_data() ad["H_nuclei_density"] I have traced this as far as the following. In the call to create_field_info, a YTFieldNotFound exception is raised on line 137 of yt/fields/species_fields.py. Here, the nuclei density field function is trying to access a number density field that should exist, but doesn't seem to at the moment. Later on it does, but not at this moment. Does anyone have any advice for where to look next? Thanks, Britton

3 5

Issue #916: Geometric fields cannot be used in the definition of a fluid field (yt_analysis/yt)
by Nathan Goldbaum 04 Oct '14

04 Oct '14

New issue 916: Geometric fields cannot be used in the definition of a fluid field https://bitbucket.org/yt_analysis/yt/issue/916/geometric-fields-cannot-be-u… Nathan Goldbaum: This causes an error in the way the FITS frontend is currently setup, minimally reproducible script is here: ``` #!python import yt import numpy as np ds = yt.load("xray_fits/A2052_merged_0.3-2_match-core_tmap_bgecorr.fits", auxiliary_files=["xray_fits/A2052_core_tmap_b1_m2000_.fits"]) def _counts(field, data): exposure_time = data.get_field_parameter("exposure_time") return data["flux"]*data["pixel"]*exposure_time ds.add_field(name="counts", function=_counts, units="counts", take_log=False) ``` The problem is that the `('fits', 'pixel')` field depends on the `('index', 'ones')` field, which doesn't get generated until after the `pixel` field is created.

1 0

Binary wheel distribution?
by Nathan Goldbaum 02 Oct '14

02 Oct '14

Hi all, Recently the python packaging ecosystem has come up with a new way of sharing binary builds of python packages to end users. This takes the form of so-called "binary wheels" (everything in python packaging is a joke about cheese...). The main advantage of wheels is that users installing via pip on Windows and OSX will no longer need compilers to build yt and installation will also proceed significantly faster. As far as I can tell, wheels are discouraged on Linux since it's assumed that users will use their OS package manager to install binary builds. You may even be using wheels right now - matplotlib, numpy, and many other projects with c extensions are now distributing wheels on OS X and windows. More information about wheels is available here: http://wheel.readthedocs.org/en/latest/ https://python-packaging-user-guide.readthedocs.org/en/latest/ The main downside of wheels is that it's another piece of tooling to maintain. I just tested and with a newish version of setuptools and the "wheel" package installed, our setup script can produce wheels! You just need to do "python setup.py bdist_wheel". I'm curious whether people would be agreeable in principle to uploading wheels to PyPI as a (semi-)automated part of our release process. Please let me know what you think. -Nathan

3 5

axes units behaving correctly?
by Chris Malone 02 Oct '14

02 Oct '14

All, I'm seeing some behavior[1] with units of axes that seems counter-intuitive, but maybe I need to change my intuition. In particular, if one makes a slice plot, but specifies the width of the plot in units of 'code_length' - for example, from using domain_right_edge - the units aren't properly converted to whatever was set as `ds.length_unit`. Is this working as intended? Are users expected to manually apply `.in_cgs()` to such items that have code_length? Naively, I would expect that when units are displayed, if they are code_* units, they should be converted to whatever is declared in `ds._set_code_unit_attributes`. [1] http://nbviewer.ipython.org/urls/dl.dropbox.com/s/bf62wclpjduvlit/example.i… Chris

2 9