yt-dev June 2015

yt-dev@python.org

18 participants
23 discussions

by Nathan Goldbaum

Hi all, A while back we were intending to backport bugfixes from the yt branch to the stable branch and then regularly issue bugfix releases. This hasn't happened, and new users in particular feel the pain this causes. Does someone want to volunteer to backport bugfix pull requests to the stable branch? It should be more or less automatic, although you will likely need to do it one pull request at a time, and it will be hard to review. This would be a great, relatively straightforward if tedious task to do at the scipy sprints, if anyone is going to that. Should we just abandon this idea and go ahead and release 3.2 sooner rather than later? Is there a way to sustainably make sure bugfixes eventually make their way to the stable branch, either with or without changing our development workflow? -Nathan

4 years, 9 months

Weekly PR Triage Hangout

by Hilary Egan

Hi all, At yesterday's yt team meeting we discussed the need to deal with open PRs on a more regular basis, so we've decided to start a weekly PR triage hangout. If you think you'll participate, here's a doodle poll <http://doodle.com/a5943ysntaddmc4f> for times. Treat the poll as "your average summer week" (as much as that concept exists), rather than these specific dates. To respect everyone's other commitments and times, each session will only run for one hour. Here's the link again: http://doodle.com/a5943ysntaddmc4f Thanks everyone! -Hilary

4 years, 9 months

yt team meeting tomorrow

by Britton Smith

Hi everyone, We will have a yt developer team meeting tomorrow at 2pm EDT, 11am PDT. These are regularly scheduled meetings to discuss the state of the project. The meeting will be held in a yt hangout and all are welcome to attend and voice their opinions. We may need to invite people to the hangout, so if you'd like to come, just let me know and I'll make sure you're included. Below is a rough agenda, but if there's something you'd like to discuss, bring it along. Britton 1. Adopting astropy code of conduct 2. Improving the PR review process 1. regular PR review hangouts 2. some other thing 3. Section updates 4. Project infrastructure evaluation 1. Is the doc system working? 2. Is Slack a good idea? 3. Do bugs on the tracker work?

4 years, 9 months

VRPR Hangout

by Matthew Turk

Hi all, Tomorrow, Andrew, Cameron and I will be hanging out about the VR PR. Ping me *off-list* if you want to join in. 12:30 PM Central time. -Matt

4 years, 9 months

Fwd: [Matplotlib-users] ANN: pytest-mpl v0.2

by Nathan Goldbaum

This is interesting. We do something similar in our current test setup, but it's nice to see this sort of thing become part of a testing library. Looking into moving from nose to py.test should definitely be on our radar given the migration of the Python community in that direction over the past year or two. py.test has some interesting features (like test fixtures) that might make it easier for us to write tests going forward. That said, the answer testing framework is quite complicated, and it might take some effort to port that. I hope to look at this myself in the coming months, but if anyone wants to take up the slack in looking at the feasibility of us in py.test, while I start my new position, feel free to try. Nathan ---------- Forwarded message ---------- From: *Thomas Robitaille* <thomas.robitaille(a)gmail.com> Date: Thursday, June 25, 2015 Subject: [Matplotlib-users] ANN: pytest-mpl v0.2 To: matplotlib-users(a)lists.sourceforge.net Hi everyone, I have just released a small plugin for py.test that wraps the image comparison functionality in matplotlib.testing, for use in other packages that use py.test as the testing framework instead of nose: https://github.com/astrofrog/pytest-mpl The idea is to make it easy to write a test such as: @pytest.mark.mpl_image_compare def test_succeeds(): fig = plt.figure() ax = fig.add_subplot(1,1,1) ax.plot([1,2,3]) return fig which can then be run in three ways: - Running py.test as usual will simply check the tests run but won't check whether the figure is correct. - Running py.test with the --mpl option will make sure that the figure produced by the test is the same as a reference image - Running py.test with the --mpl-generate-path option will generate the reference images from the tests themselves. There are a number of other options, including ways to pass arguments to savefig, customizing the image names, or setting the tolerance for the comparison. All the documentation is contained in the README.md file: https://github.com/astrofrog/pytest-mpl/blob/master/README.md You can install this plugin with: pip install pytest-mpl I would welcome any feedback and/or contributions! Cheers, Tom ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Matplotlib-users mailing list Matplotlib-users(a)lists.sourceforge.net <javascript:;> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

4 years, 9 months

Issue #1038: Update sketchfab export docs (yt_analysis/yt)

by Nathan Goldbaum

New issue 1038: Update sketchfab export docs https://bitbucket.org/yt_analysis/yt/issue/1038/update-sketchfab-export-docs Nathan Goldbaum: This page still uses the outdated ds['kpc'] construction: http://yt-project.org/docs/dev/visualizing/sketchfab.html?highlight=sketchf…

4 years, 9 months

Issue #1037: Units system has problems in comparing between cosmological datasets with different scale factors (yt_analysis/yt)

by Cameron Hummels

New issue 1037: Units system has problems in comparing between cosmological datasets with different scale factors https://bitbucket.org/yt_analysis/yt/issue/1037/units-system-has-problems-i… Cameron Hummels: At present, when you try to compare/combine quantities from two separate datasets, yt defaults to internally converting those quantities to non-comoving physical units before making the comparison/operation. I think this *should* be the default behavior as it covers the bulk of the use cases, but it would be good to allow for comparisons/combinations using comoving units (of different scale factors) as well. I recently ran into this issue in trying to compare two separate datasets at different redshifts (ie scale factors) from a cosmological simulation where the units were enzo's `code_length`, which is in comoving units. In the end, I had to just grab the `.v` values out of the `YTArray` in order manually subtract them because subtracting using the `YTArray` yielded incorrect answers. Here is an example demonstrating this problem. Let's say a galaxy sits at the center of this box at both z=99 and z=0. we can see how far it has moved in comoving units by subtracting off it's position at z=0 from it's position at z=99. http://paste.yt-project.org/show/5655/ and its output: http://paste.yt-project.org/show/5656/ I think this could be addressed by just creating an additional attribute on `YTArrays` for converting to comoving units when making comparisons/operations with other `YTArrays`.

4 years, 9 months

Issue #1036: BinnedProfile1D seems to be broken (yt_analysis/yt)

by Mark Krumholz

New issue 1036: BinnedProfile1D seems to be broken https://bitbucket.org/yt_analysis/yt/issue/1036/binnedprofile1d-seems-to-be… Mark Krumholz: It seems that BinnedProfile1D does not work correctly in yt3.1, at least in some cases. Using it with a derived field appears to produce unpredictable results. An example script that should work but doesn't seem to is at http://paste.yt-project.org/show/5648/. Since I am informed that BinnedProfile1D is obsolete and has been replaced by create_profile, perhaps it should just be removed, or deprecation warnings should be added.

4 years, 9 months

Issue #1035: defining a bounding box causes units problems in tipsy data sets (yt_analysis/yt)

by Desika Narayanan

New issue 1035: defining a bounding box causes units problems in tipsy data sets https://bitbucket.org/yt_analysis/yt/issue/1035/defining-a-bounding-box-cau… Desika Narayanan: Hey All, FYI, this may be related to [PR # 1524](https://bitbucket.org/yt_analysis/yt/pull-request/1524/added-function… If I run the following on the tipsy data set: ``` import yt import numpy as np fname = 'TipsyGalaxy/galaxy.00300' boxsize = 100 bbox = [[-boxsize,boxsize], [-boxsize,boxsize], [-boxsize,boxsize]] ds = yt.load(fname,bounding_box=bbox) ds.index px = yt.ProjectionPlot(ds,"z",('deposit', 'Gas_density'),center='m') px.save('junk.z.png') ``` I'll get an image back out that has the galaxy as 50 cm big! However, if I run the same code but replace the load command with: ``` ds = yt.load(fname) ``` then no problem. Another way this manifests itself is if I load with the bounding_box set in the load command, then: ``` In [11]: ds.length_unit Out[11]: 1.0 kpc In [12]: ds.domain_left_edge Out[12]: YTArray([-100., -100., -100.]) code_length In [13]: ds.domain_left_edge.in_units('kpc') Out[13]: YTArray([ -3.24077929e-20, -3.24077929e-20, -3.24077929e-20]) kpc ``` I've looked through frontends/tipsy/data_structures and can't seem to figure what's doing this. Again, this might not be related to this PR, but it sure seems similar.

4 years, 9 months

Status of a few big PRs

by Matthew Turk

Hi all, There are a few big PRs still open. I wanted to update you on them: * VR refactor: https://bitbucket.org/yt_analysis/yt/pull-request/1256/wip-volume-rendering… . This is ready for review. * Particle octree refactor: https://bitbucket.org/yt_analysis/yt/pull-request/1206/wip-forest-of-octrees . This will simply not work in its current form. I have redesigned it around nested bitmap indices but not yet pushed to my fork; I'm hoping to get to it sometime in the next few weeks. * Hybrid Rockstar: https://bitbucket.org/yt_analysis/yt/pull-request/1618/wip-hybrid-rockstar . Hilary has done some awesome work on this, and I think that it will work nicely, but parallelism might need some help (according to her bullet points) * Grid visitors: The preliminary PR was accepted, and I am working on a new set of PRs that will enable this broadly. This should reduce memory overhead. * OpenGL volume rendering: https://bitbucket.org/yt_analysis/yt/pull-request/1598/opengl-volume-render… . This is blocked on the VR refactor, and once that is in I'll continue to update this to utilize the new scene objects. -Matt

4 years, 9 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev June 2015