Mailman 3 March 2017 - yt-dev

Issue #1336: Field parameters that yt doesn't know about are assumed to be dimensionless (yt_analysis/yt)
by Nathan Goldbaum March 20, 2017

March 20, 2017

New issue 1336: Field parameters that yt doesn't know about are assumed to be dimensionless https://bitbucket.org/yt_analysis/yt/issues/1336/field-parameters-that-yt-d… Nathan Goldbaum: Consider the following script: ``` import yt from yt.fields.derived_field import ValidateParameter def _overdensity(field, data): rhobar = data.get_field_parameter('rhobar') return data[('ramses', 'Density')]/rhobar - 1. ds = yt.load('output_00080/info_00080.txt') ad = ds.all_data() rhobar = ad.… [View More]

1 0

Nominate Alex Lindsay as a project member
by Nathan Goldbaum March 14, 2017

March 14, 2017

Hi all, I'd like to nominate Alex Lindsay as a project member. He has been working on improving support for unstructured mesh data in general and the Exodus II frontend in particular. Currently Alex has about 70 commits in the main repo and has worked on several pull requests. We need two more seconds to officially add him as a member. Once that happens I will update the relevant places on bitbucket, the website, and the YTEP repo. If you'd like to learn more about membership in the yt … [View More]

6 5

Issue #1335: Add second order support for QUADS (yt_analysis/yt)
by Alexander Lindsay March 14, 2017

March 14, 2017

New issue 1335: Add second order support for QUADS https://bitbucket.org/yt_analysis/yt/issues/1335/add-second-order-support-f… Alexander Lindsay: MOOSE users fairly commonly use second order LAGRANGE polynomials on quad elements; want to natively support visualization on such elements without reverting to first order.

1 0

Issue #1334: Yt misinterpretes gizmo binary files of type one (yt_analysis/yt)
by Christoph Bischko March 10, 2017

March 10, 2017

New issue 1334: Yt misinterpretes gizmo binary files of type one https://bitbucket.org/yt_analysis/yt/issues/1334/yt-misinterpretes-gizmo-bi… Christoph Bischko: [Gizmo](https://bitbucket.org/phopkins/gizmo) binary files of type 1 (oldest type, no hdf5, no 4 character block delimiters) are not read/recognized correctly by yt. Gizmo has introduced two additional integer-sized blocks (`CHILD_ID` and `GENERATION_ID`) for **all** particle types (gas, halo, disk, bulge, stars, boundary). So the … [View More]

1 0

Issue #1333: Exception Ignored from yt.geometry.particle_deposit.SumParticleField.process (yt_analysis/yt)
by Desika Narayanan March 9, 2017

March 9, 2017

New issue 1333: Exception Ignored from yt.geometry.particle_deposit.SumParticleField.process https://bitbucket.org/yt_analysis/yt/issues/1333/exception-ignored-from Desika Narayanan: When loading a sub-region of a gizmo snapshot, and trying to create an arbitrary grid, the code gives (numerous prints of) an error: ``` Exception IndexError: 'Out of bounds on buffer access (axis 2)' in 'yt.geometry.particle_deposit.SumParticleField.process' ignored``` An example code that reproduces this is … [View More]

1 0

ANN: yt 3.3.5 released
by Nathan Goldbaum March 8, 2017

March 8, 2017

We are proud to announce the release of yt 3.3.5! yt (http://yt-project.org) is an open-source, community-developed toolkit for analysis and visualization of volumetric data. Version 3.3.5 is a regularly scheduled bugfix release including fixes for a number of issues reported since the release of yt 3.3.4. We urge all users to update to the latest version. If your python installation is managed via conda, update following: $ conda update -c conda-forge yt If your python installation is … [View More]

1 0

Changes to yt source code hosting
by Matthew Turk March 7, 2017

March 7, 2017

Hi everyone, The yt steering committee (Hilary Egan, Nathan Goldbaum, Cameron Hummels, Kacper Kowalik, Sam Skillman, Britton Smith, Matthew Turk and John ZuHone) proposes that we move the hosting infrastructure for yt from BitBucket to GitHub, and as a side effect, migrate the primary version control system from mercurial to git. This decision wasn’t taken lightly, and it’s with more than a little sadness that I’m writing this email. Beneath the “next steps” stuff, I’ve detailed some of the … [View More]rationale behind this, and outlined some of our thinking. First, however, I’ll outline the next steps and what this means for the (overlapping, non-disjoint) developer and user communities. What’s Next: * This email is to serve as a solicitation of comments; if you wish to just say, “+1” or “me too” or anything along those lines, please feel free to not send that email. If you have reservations, concerns to raise, suggestions for the conversion process itself, or opinions about the outline, please do contribute. * The conversion process and plans for migrating code, issues, etc will be detailed in a YTEP. What will almost certainly happen is that for a period of time, we’ll have mirrors on both GH and BB, but at any given time only one will be open for pull requests and code review. (i.e., there’ll be a switch-flipping at some point to move, but we’ll ease into it.) We anticipate this will be on the scale of months, not hours or days. * We decide on a timeline for when we turn off pull requests on the old repository and turn them on on a new one. * We’ll be figuring out how to move infrastructure (fido) to GitHub as part of the YTEP. What this means for you as someone who contributes, or runs off the mainline: * At some point in the future, you will need to issue pull requests to a repository on GitHub. * Code reviews will happen on GitHub, and our process may change slightly. * The yt repository on BitBucket will, for the foreseeable future, be available, and we will mirror changes from GH for at least the mid-term future, potentially much longer. All previous code reviews will be backed up, but for reference will continue to be available on BitBucket. * If you auto-update and want to push changes back up, you’ll be grabbing from another place; this likely means re-cloning. What this means for someone who runs yt: * If you are using nightly or stable builds from pip, anaconda or conda-forge, you should have no interruption whatsoever. * If you’re running from the source repository, you may or may not need to re-clone (with git), depending on the timescale of the mirror continuing to run. Big Things To Discuss: * When we do flip the BB->GH switch is not clear; there are arguments to be made for both “right away” and “in the summer.” There are some big in-flight PRs that maybe should go in before we move. * We’ll need to decide about things like squashing commits, rebasing, etc. That can happen later. I suppose that’s it. Thanks for reading. Unless we hear big objections, we’ll draft a YTEP in the next week or two with some more information, and then use that as an opportunity to finalize a timeline. -Matt, on behalf of the yt steering committee Appendix: Rationale I’ll start this out with a personal comment. Discussions about this have happened from time to time. I’d always, always pushed back. (I wasn’t the only one, but I was usually pretty vocal.) This time, I was the one who brought it up. My reasoning, which is certainly not original, is that there are two main reasons we should move. I want to emphasize neither of these is related to hg; in fact, I’m incredibly sad about hg, and only a little sad about leaving bitbucket. I’ll probably still use hg-git to manage git via hg, and I’ll still happily talk about how amazing hg is. Reason 1: It’s an inclusion issue. There is evidence that any additional barriers to entry dramatically reduce participation in the development of open source projects, and there is evidence that these barriers disproportionately affect underrepresented and minoritized groups. We have seen a decline in new contributions to yt. Furthermore, the regular contributors to yt do not match the diversity of the astronomical community (which, despite our efforts to be interdisciplinary, is still our original home.) Asking people to jump through additional hurdles helps neither of these problems. Reason 2: There is an ecosystem around GitHub that we are not able to participate in. Things like depsy.org, the other astronomy or physical sciences projects, and the like. The advantage of a monoculture (lowering barriers to entry) is also the disadvantage of a monoculture in terms of an ecosystem. By moving to GitHub, we will gain access to this ecosystem. I could go on at length about these two reasons, but I’ll just leave it there. For me, the first reason is the vastly more important one, but both are valid. This decision wasn’t taken lightly, and a number of issues were raised -- not the least of which is reducing disruption to people that are either clearly “users” or “developers” as well as the community of dev-users. One issue that has been brought up is that every “disrupt people’s workflow” token we spend has a real cost, and we should not use them lightly. What we arrived at, which was a consensus if not a consensus that left everyone entirely happy, was that this case is worth one of those tokens. -Matt, on behalf of himself [View Less]

1 0

Issue #1332: Abiity to read a small subset of files in a multipart GADGET binary snapshot (yt_analysis/yt)
by Anonymous March 5, 2017

March 5, 2017

New issue 1332: Abiity to read a small subset of files in a multipart GADGET binary snapshot https://bitbucket.org/yt_analysis/yt/issues/1332/abiity-to-read-a-small-sub… Anonymous: In many situations it so happens that the data of the GADGET snapshot output is extremely large (mine is around 1 TB) and is divided into many parts in binary files. It becomes necessary to sometimes use only a few of these files instead of the entire dataset maybe for running some initial analyzing test codes. … [View More]

1 0

RFC: updating API docs
by Kacper Kowalik March 4, 2017

March 4, 2017

Hi all! I'd like to bring PR 2526 to your attention. It introduces small, but significant changes to the way how the API reference is built. Most notably: it generates a one html page per *module* with classes and methods as subsections, instead of a one page per method (as we do now). An example deployment can be browsed here: http://yt-project.org/docs/mock There are couple of pros to this approach: * The build time is greatly reduced. It shaves a 0.5h from the total build time on our … [View More]

2 2

Issue #1331: Happy Birthday Sis (yt_analysis/yt)
by Anonymous March 4, 2017

March 4, 2017

New issue 1331: Happy Birthday Sis https://bitbucket.org/yt_analysis/yt/issues/1331/happy-birthday-sis Anonymous:

1 0