yt-dev April 2017

yt-dev@python.org

9 participants
16 discussions

by Nathan Goldbaum

Hi all, Thanks to efforts from Kacper, Matt, and myself we now have a working github mirror: https://github.com/yt-project/yt-test This repo is available purely for testing purposes. It should always be in sync with the latest changes in the bitbucket repository. There is a chance that we will need to redo the conversion and change all the hashes so don't rely on this repo being here forever. In addition, Kacper has verified that our Jenkins test suite works more or less out of the box on a repo on github, so it should be pretty easy to set up continuous integration on github when we "flip the switch". Matt set up a repo on github to track the migration process: https://github.com/yt-project/bb-migration/issues If you'd like to help out then then that issue tracker is probably the first place you should look. According to the YTEP tracking this process ( https://bitbucket.org/yt_analysis/ytep/pull-requests/68/), we are about halfway done with "stage 1". I think these two issues would be perfect for someone who hasn't been involved up until now to take on: * Updating the code for "yt update" to work properly with an installation from a git checkout of yt. We might explore adding an optional dependency on gitpython (http://gitpython.readthedocs.io/en/stable/) for this. * Migrate the supplemental repositories. This is very straightforward, just tedious because the same steps need to be repeated for all the repos. Finally if you have push access to the main yt repo (that generally means that you are a yt project "member") then you should comment on this issue so we know what your github username is: https://github.com/yt-project/bb-migration/issues/8 I'd say we're on pace for making the switch Soon (TM). -Nathan

4 years

Issue #1344: Metallicity is broken in the stream frontend for grid data (yt_analysis/yt)

by John ZuHone

New issue 1344: Metallicity is broken in the stream frontend for grid data https://bitbucket.org/yt_analysis/yt/issues/1344/metallicity-is-broken-in-t… John ZuHone: If one sets up a stream dataset with metallicity as an input field, the values get transformed. A simple script demonstrates this: ```python import numpy as np import yt Z = np.random.uniform(size=(32,32,32)) d = np.random.uniform(size=(32,32,32)) data = {"density": d, "metallicity": Z} ds = yt.load_uniform_grid(data, (32,32,32)) dd = ds.all_data() print(Z.max()) print(dd["metallicity"].max()) ``` gives: ```pycon 0.99996801409647373 0.012949585782549334 dimensionless ``` This happens regardless if one sets the units in the dict above. I am pretty sure that somehow the derived field for `metallicity` is being used instead, because that rescales `metal_density` by the solar value, and somehow the input field is getting interpreted as `metal_density`. This bug got accidentally introduced in yt 3.3.2 with this PR: https://bitbucket.org/yt_analysis/yt/pull-requests/2331/adding-metallicity-… I'll see if I can track it down. Responsible: jzuhone

4 years

Issue #1343: The install script should bail on unsupported operating systems (yt_analysis/yt)

by Nathan Goldbaum

New issue 1343: The install script should bail on unsupported operating systems https://bitbucket.org/yt_analysis/yt/issues/1343/the-install-script-should-… Nathan Goldbaum: Right now it tries to download miniconda from an invalid URL

4 years

migration ytep

by Matthew Turk

Hi folks, Here's a draft YTEP about migration: https://bitbucket.org/yt_analysis/ytep/pull-requests/68/adding-draft-github… I'll update with comments soon, once a sample conversion has been made and put on the GH page. Comments are welcome, but right now, it'd be much more useful if they were along the lines of "here's something that also will need to be done" since this is in its early phases. But, it's also probably true that we can start moving forward with phase 1 toward phase 2 already. -Matt

4 years

yt team meeting 8: Wednesday, April 19 at 4pm EDT

by Britton Smith

Hi everyone, We've landed on Wednesday, April 19 at 4pm EDT (1pm PDT) for the next team meeting. If you were on the scheduling poll, I'll make sure you'll get an invite to the hangout. If anyone else would like to join, just send me an email. See you then. Britton

4 years

New default particle union?

by Nathan Goldbaum

Hi all, I'd like to propose adding a new particle union that should be defined for all datasets that include particles. This came up in the context of the demeshening work (see https://bitbucket.org/yt_analysis/ytep/pull-requests/67 for more details). Right now many of the derived quantities make a distinction between calculating results using just the gas or just the particles or both. Up until now they have calculated the results for particles using particle fields from the 'all' particle union. This makes perfect sense for AMR data but doesn't really make sense for SPH data, since it will double-count SPH particles. In fact, I think this is an issue even without the demeshening, but the demeshening makes it more starkly apparent. I'd like to propose defining a new "n-body" particle union (suggestions for alternate names are very welcome) that will be defined for all yt datasets. This union will be identical to the 'all' particle union for AMR data and N-body particle data, but for SPH data will only include the particle types that aren't SPH particles (if any). That means the "n-body" particle type represents infinitesimal particles but not particles that have finite extents (e.g. an SPH particle's smoothing region). I think this new particle type would probably be generically useful beyond just the derived quantities, maybe even more useful than "all". I also kind of prefer the name "n-body" to "all" since it more prominently indicates that it's associated with particle data. Please let me know if you have thoughts or suggestions about this proposal. I'm happy to draft a YTEP or update YTEP-0031 with more details if people want to see that. -Nathan

4 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev April 2017