Mailman 3 January 2015 - yt-dev

Re: [yt-dev] 3.1: PRs to merge
by John ZuHone 14 Jan '15

14 Jan '15

Yes, unfortunately, so I apologize for ranting about it. > On Jan 13, 2015, at 6:41 PM, Cameron Hummels <chummels(a)gmail.com> wrote: > > So this is what you were referencing in IRC today. I only *just* received this, despite it being sent yesterday. Weird. Anyway, perhaps there was a problem in the mail routing, which is why people weren't responsive to it? > > Good luck with everything! > > Cameron > > ---------- Forwarded message ---------- > From: John ZuHone <jzuhone(a)gmail.com <mailto:jzuhone@gmail.com>> > Date: Mon, Jan 12, 2015 at 12:44 PM > Subject: [yt-dev] 3.1: PRs to merge > To: yt-dev(a)lists.spacepope.org <mailto:yt-dev@lists.spacepope.org> > > > Hi all, > > Since we’re trying to get 3.1 out soon (today if possible), we’d like some more eyeballs to go over the following PRs, which barring any other comments are ready to go: > > https://bitbucket.org/yt_analysis/yt/pull-request/1400/check-if-pyfits-is-n… <https://bitbucket.org/yt_analysis/yt/pull-request/1400/check-if-pyfits-is-n…> > > https://bitbucket.org/yt_analysis/yt/pull-request/1398/controlling-the-dept… <https://bitbucket.org/yt_analysis/yt/pull-request/1398/controlling-the-dept…> > > https://bitbucket.org/yt_analysis/yt/pull-request/1394/gadget-temperature-f… <https://bitbucket.org/yt_analysis/yt/pull-request/1394/gadget-temperature-f…> > > https://bitbucket.org/yt_analysis/yt/pull-request/1381/positions-and-veloci… <https://bitbucket.org/yt_analysis/yt/pull-request/1381/positions-and-veloci…> > > There was some contention over the last one in particular. Please indicate your approval on each PR, or if you think something is missing please comment. > > Best, > > John Z > > > > _______________________________________________ > yt-dev mailing list > yt-dev(a)lists.spacepope.org <mailto:yt-dev@lists.spacepope.org> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org> > > > > > -- > Cameron Hummels > Postdoctoral Researcher > Steward Observatory > University of Arizona > http://chummels.org <http://chummels.org/> _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1

Issue #974: OffAxisProjectionPlots with RAMSES and particle data (yt_analysis/yt)
by Benjamin Thompson 13 Jan '15

13 Jan '15

New issue 974: OffAxisProjectionPlots with RAMSES and particle data https://bitbucket.org/yt_analysis/yt/issue/974/offaxisprojectionplots-with-… Benjamin Thompson: Hello. I am trying to produce an off axis projection plot with RAMSES using YT. More specifically using the star (or particle) density deposit field. It works fine for gas (although since this data object is only 10 kpc thick, there are odd "grating like" lines in the image ![test_off_axis.png](https://bitbucket.org/repo/BXbAb/images/1487888224-test_off_axis.png) But when it comes to producing an off axis plot of stellar density, I get this output ``` #!python yt : [INFO ] 2015-01-13 15:31:56,772 xlim = -0.001753 0.001753 yt : [INFO ] 2015-01-13 15:31:56,772 ylim = -0.001753 0.001753 yt : [INFO ] 2015-01-13 15:31:56,772 zlim = -0.001753 0.001753 yt : [INFO ] 2015-01-13 15:31:56,772 Making a fixed resolutuion buffer of (('deposit', 'stars_density')) 800 by 800 ``` and then the terminal crashes Any idea why this might be the case? Ben _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

3.1
by John ZuHone 13 Jan '15

13 Jan '15

Hi all, Nathan and I had thought about possibly doing the 3.1 release today—let me know if there are any objections. John Z _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1

Issue #973: Sliceplot of 2D cylindrical data (yt_analysis/yt)
by Andrea Derdzinski 12 Jan '15

12 Jan '15

New issue 973: Sliceplot of 2D cylindrical data https://bitbucket.org/yt_analysis/yt/issue/973/sliceplot-of-2d-cylindrical-… Andrea Derdzinski: When I try to make a sliceplot of output from a 2D cylindrical FLASH simulation, ``` #!python from yt.mods import * pf = load('disc_hdf5_plt_cnt_0000') #attached slc = SlicePlot(pf, 'theta', 'dens') ``` but I get the following error: File "/Users/Shark/yt-x86_64/src/yt-hg/yt/visualization/plot_window.py", line 1842, in SlicePlot return AxisAlignedSlicePlot(ds, normal, fields, *args, **kwargs) File "/Users/Shark/yt-x86_64/src/yt-hg/yt/visualization/plot_window.py", line 1017, in __init__ window_size=window_size, aspect=aspect) File "/Users/Shark/yt-x86_64/src/yt-hg/yt/visualization/plot_window.py", line 618, in __init__ PlotWindow.__init__(self, *args, **kwargs) File "/Users/Shark/yt-x86_64/src/yt-hg/yt/visualization/plot_window.py", line 210, in __init__ self.data_source.center, ax) File "/Users/Shark/yt-x86_64/src/yt-hg/yt/geometry/coordinates/coordinate_handler.py", line 184, in sanitize_center return self.ds.arr(center), self.convert_to_cartesian(center) File "/Users/Shark/yt-x86_64/src/yt-hg/yt/geometry/coordinates/cylindrical_coordinates.py", line 146, in convert_to_cartesian return cylindrical_to_cartesian(coord) NameError: global name 'cylindrical_to_cartesian' is not defined _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

Fun project?
by Matthew Turk 12 Jan '15

12 Jan '15

Hi all, Just saw this: https://ospray.github.io/ Seems like exporting volumes from yt into this would be a fun project, particularly in-memory. -Matt _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

3.1: PRs to merge
by John ZuHone 12 Jan '15

12 Jan '15

1 0

Issue #972: Can't use attoseconds (yt_analysis/yt)
by John ZuHone 06 Jan '15

06 Jan '15

New issue 972: Can't use attoseconds https://bitbucket.org/yt_analysis/yt/issue/972/cant-use-attoseconds John ZuHone: Not really a big deal, but I noticed today you can't use attoseconds because prefixing "s" with "a" doesn't work: ```python yt.YTQuantity(1.0,"as") File "<string>", line 1 as ^ SyntaxError: invalid syntax ``` Responsible: jzuhone

1 0

Issue #971: yt-3.0 gadget InternalEnergy field unit (yt_analysis/yt)
by Junhwan Choi 05 Jan '15

05 Jan '15

New issue 971: yt-3.0 gadget InternalEnergy field unit https://bitbucket.org/yt_analysis/yt/issue/971/yt-30-gadget-internalenergy-… Junhwan Choi: Hi yt developers, I would like to file a bug related with gadget(spy) field. I (and Nathan Goldbaum) found that the InternalEnergy field in yt/frontends/sph/fields.py is read as dimensionless. Indeed, the unit of the gadget InternalEnergy is Velocity_unit**2. For example, if the unit is defined as follow: unit_base = {'UnitLength_in_cm' : 3.08568e+21, 'UnitMass_in_g' : 1.989e+43, 'UnitVelocity_in_cm_per_s' : 100000} The Internal Energy unit is (km/s)**2 If it is possible that I would like to ask to set up the temperature field for gadget dataset. Indeed, the gadget output only generates the InternalEnergy and temperature need to be estimated from the InternalEnergy and chemical abundance (if there are). Although it is possible to generate the derived temperature field, the temperature is very basic quantity and it may need to computed for both particle and cell. Thank you, Junhwan

1 0

Field naming proposal
by Nathan Goldbaum 05 Jan '15

05 Jan '15

Hi all, I've just issued a pull request that bears some developer discussion. Right now yt is a bit of a wild west in terms of the field naming convention for fields that reference a coordinate system. See for example, see issue 947: https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-… I'd like to propose a naming convention for fields that reference a coordinate system. Gas and particle fields should be of the form: (field_type, "<particle?>_<vector_field_name>_<coordinate>") while index fields for coordinates should be of the form: ("index", "<coordinate>") This fits within our existing field naming convention for cartesian coordinates, e.g.: ("gas", "velocity_x") (ptype, "particle_velocity_y") as well as our convention for index coordinate fields, e.g.: ("index", "x") ("index", "spherical_theta") This means that index fields do not need to explicitly reference themselves as positions. So we *won't* have field names like: ("index", "position_x") I don't like the above construction because it's a bit redundant ("index" implies that we are talking about a position or something similar). Some existing field names will need to be changed to fit this. In particular, some of the index fields will need to be renamed to be more verbose ("index", "spherical_r") becomes ("index", "spherical_radius") and (ptype, "particle_spherical_position_radius") becomes (ptype, "particle_position_spherical_radius"). Wherever an existing field name needs to change, I propose we mark the existing field name for deprecation, stub it out, and make it an alias for the field with the new field name. In a future release, we can then remove the deprecated fields. I've implemented this for the particle fields (for the most part) in PR 1378: https://bitbucket.org/yt_analysis/yt/pull-request/1378 I'm happy to update the field naming YTEP if this proposed field naming scheme gets approval in this thread. What do you all think? Question, concerns? -Nathan _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

9 20

Issue #970: bug in PPVcube viewing angle to FITS (yt_analysis/yt)
by Roger Deane 05 Jan '15

05 Jan '15

New issue 970: bug in PPVcube viewing angle to FITS https://bitbucket.org/yt_analysis/yt/issue/970/bug-in-ppvcube-viewing-angle… Roger Deane: Hi Firstly, thank you for this excellent piece of software. I am using the PPVcube class to write to FITS images and cubes (essentially, what is being done in this example: http://yt-project.org/doc/analyzing/analysis_modules/ppv_cubes.html) I have come across what seems to be a bug in changing the viewing angle of the rotating disk (parameter "L" in the above tutorial). An aside: I think L should be L = [0.0,np.sin(i),np.cos(i)]; not what is currently set in the tutorial: L = [0.0,np.sin(i),np.sin(i)] I've attached a script which is simply the original PPVCube.py script from the above webpage with an additional for loop to write out FITS images at inclination angles of 0,10,20,...,90 degrees. All that is changed is the "L" parameter. One key difference is that I write out a FITS cube with 1 velocity plane, as one would do if you would like to make a "total intensity or moment 0" map of CO or HI emission. If you run the script, you'll produce 10 FITS images with the above inclinations. If you compare the FITS images you'll notice two strange things: 1) the inclination = 0 FITS image should be rotationally symmetric about the origin, but it is not. The effect of this is also seen in the higher inclination FITS images. 2) There is a 90 degree rotation of this asymmetry between the 20 and 30 degree inclination FITS images (more specifically between 26 and 27 degrees). I suspect the issue is possibly caused by the fact that I am writing out to a single velocity channel. I hope I have missed anything obvious that is causing this. I am running the developer version of yt 3.0.2 and have updated. I am under time pressure and need to decide whether to use yt or reluctantly switch to a much older, less flexible package. So I would greatly appreciate a confirmation of this perceived bug and a possible workaround or fix. Many thanks Roger

1 0