Mailman 3 November 2014 - yt-dev

Data affiliated with publications
by Matthew Turk 06 Nov '14

06 Nov '14

Hi all, If you have data you would like to make available (of any size) that is affiliated with a publication, would you mind pinging me off list? I'll have more info later, but Kacper and I have been working on a project for NDSLabs (affiliated with nationaldataservice.org) and we're looking to populate it with Real Data that's of Real Use. Our near-term deadline is SC14. -Matt

1 0

yt 3.1?
by Nathan Goldbaum 05 Nov '14

05 Nov '14

Hi all, There have been a number of cool new features in the pull request queue recently. Some of these have added new features and I think it might be worthwhile to indicate that by bumping the minor version number on the next release. I think it would be a good idea to try to integrate the open PRs as well as any that come in over the next couple of weeks that can be reviewed, call it yt 3.1 and release on or around Dec. 1. This will mean generating a proofread docs build and perhaps a few days of low-hanging issue triaging. I'd nominate John ZuHone to send out the release email to recognize the hard work he's been putting in recently. Just an idea, but I've tried to include specifics as a basis for further discussion. What do you all think? Nathan

9 26

Issue #935: Particle Density Projection for Flash Data (yt_analysis/yt)
by yl2501 05 Nov '14

05 Nov '14

New issue 935: Particle Density Projection for Flash Data https://bitbucket.org/yt_analysis/yt/issue/935/particle-density-projection-… yl2501: I am trying to make a particle density projection plot with Flash data. dd['deposit', 'io_density'] gives an error message: KeyError: "Unable to open object (Object 'particle_posy' doesn't exist)" dd['deposit', 'all_density'] gives the same error message.

1 0

Issue #934: Docs build is broken (yt_analysis/yt)
by Nathan Goldbaum 05 Nov '14

05 Nov '14

New issue 934: Docs build is broken https://bitbucket.org/yt_analysis/yt/issue/934/docs-build-is-broken Nathan Goldbaum: http://tests.yt-project.org/job/yt-docs-3.0/373/console It looks like one of the cookbook recipes doesn't work anymore, which breaks the docs build. It would be great if someone who has some spare time could take a look at this! It should hopefully be possible to track this down using `hg bisect` on the failing script.

2 1

Issue #933: linear bins in create_profile crash (yt_analysis/yt)
by Stephanie Tonnesen 04 Nov '14

04 Nov '14

New issue 933: linear bins in create_profile crash https://bitbucket.org/yt_analysis/yt/issue/933/linear-bins-in-create_profil… Stephanie Tonnesen: I am trying to make a profile of column density vs radius of a galaxy disk using create_profile. I would like linear bins, but cannot make it work. After some back-and-forth, Nathan Goldbaum thinks that it is a bug. Here is the code, using the RamPressureStripping available data. import yt units_override = {"length_unit":(26,"kpc"),"time_unit":(3.086e14,"s"),"mass_unit":(5.165e39,"g")} ds = yt.load("Downloads/RamPressureStripping/id0/rps.0062.vtk", units_override=units_override) alld = ds.all_data() gal = alld.cut_region("obj['density'] > 1.01e-25") logs = {('index', 'cylindrical_r'): False} profile = yt.create_profile(gal, [('index', 'cylindrical_r')], # the bin field [('gas', 'cell_mass')], # profile field weight_field=None, n_bins=17,logs=logs) coldens = profile["gas","cell_mass"]/1.6733e-24 coldens[0] = coldens[0]/(3.14159*profile.x[0]*profile.x[0]) i = 1 while i < len(coldens): coldens[i] = coldens[i]/((3.14159*profile.x[i]*profile.x[i]) - (3.14159*profile.x[i-1]*profile.x[i-1])) i = i+1 mp.plot(profile.x/3.086e21,coldens) mp.show() print profile.x

1 0

Proposed modification to YTEP-1776: bugfixes to the stable branch, code freezes
by Nathan Goldbaum 04 Nov '14

04 Nov '14

Hi all, Before making a PR to the YTEP repository, I wanted to propose a modification to our development workflow to the mailing list. In particular, I think we need to be more careful about what changes go to the yt branch and the stable branch. Right now we suggest all new changes, including bug fixes, API changes, and new features, go to the "yt" branch. Periodically, we merge from the "yt" branch into the "stable" branch, tag the merge with a release number, and upload to pypi. This means that we are restricted in making bugfix releases that include no breaking changes. As soon as a new feature gets merged into the "yt" branch, by all rights the next merge-to-stable and release should be a minor version change instead of a patch version change (i.e. we should be releasing yt 3.1 instead of yt 3.0.1 after merging in a new feature or API change, see http://semver.org/ for more details on this nomenclature). Generally, people expect patch version bumps to only include bugfixes. I'd like to propose a modification to our development workflow that should make it easier to make sure bugfixes can be released without breaking unrelated things, while still allowing us to temporarily break stuff on the dev branch. I think rather than merging from the "yt" branch into "stable" *every* time we do a release, we should instead issue patch releases from the current state of the stable branch. Instead of merging from "yt" into "stable" with every release, we should only do so before a minor or major version release, not patch releases. This means that bugfixes will need to go to the "stable" branch instead of the "yt" branch. It also means that the "stable" branch will need to be merged into the "yt" branch with some regularity to make sure bugfixes make their way to the dev version of the code. It will also take some degree of manual care to ensure that the "@" bookmark always points at the tip of the stable branch so fresh clones get bugfixes. Additionally, bugfixes may need to be backported or cherrypicked from the "yt" branch to the "stable" branch if a bugfix comes in as part of some bigger change or if a contributor isn't aware that bugfixes should go to the stable branch. This workflow sort of matches what's done in the mercurial community. I think it would be a good idea to follow the mercurial community in another way, we should institute a "code freeze" for the two weeks prior to a non-bugfix release. This means that all developers switch to the tip of the "yt" branch, and only PRs that fix bugs, documentation issues, or improve error messages can be merged. Just before release, the "yt" branch is merged into "stable". See http://mercurial.selenic.com/wiki/TimeBasedReleasePlan for more details. Instituting such a testing period should help us understand the scope of a release a few weeks out, keep pre-release documentation updates bounded, and hopefully help suss out bugs since most developers will be testing a sync'd up-to-date version of the code that people will actually be using. What do you all think about these proposals? If there's broad agreement that this is a good idea, I'll put this proposal together as a patch for YTEP-1776. If not I'll hold off for a while until we can come to a consensus. Best, Nathan

6 6

Any method to go back to yt 2.6.1 from the updated yt 3.0.2 ?
by Reju Sam John 03 Nov '14

03 Nov '14

Dear all, Just now I updated my YT. But none of my old cods are running. Is there any method to go back to my old yt 2.6.1 from the updated yt 3.0.2 ? for updating I used the following commands $ yt update $ cd /home/john/yt-x86_64/src/yt-hg $ hg up $ /home/john/yt-x86_64/bin/python2.7 setup.py develop Thank you -- Reju Sam John

1 0

Issue #932: No warning when astropy isn't installed when trying to load fits data (yt_analysis/yt)
by Jill Naiman 03 Nov '14

03 Nov '14

New issue 932: No warning when astropy isn't installed when trying to load fits data https://bitbucket.org/yt_analysis/yt/issue/932/no-warning-when-astropy-isnt… Jill Naiman: Reporting Version: 1e0faa5cb0fc+ (yt) tip When trying to load fits data (just your usual load command), I get an error like "Supplied ('/Users/jillnaiman/data/grs-50-cube.fits',) {}, but could not load!" when the file is clearly there. Its fixed by "pip install astropy", but there is no warning that this package needs to be installed for the fits loading to work.

1 0