yt-dev March 2018

yt-dev@python.org

10 participants
7 discussions

Registration open: LSSTC workshop "Data Visualization and exploration in the LSST Era" NCSA, June 19-21, 2018
by Matthew Turk 30 Mar '18

30 Mar '18

Hi folks, I am passing on the following message about an upcoming workshop. This workshop will feature a track about yt, including tutorials both basic and advanced, and I'm pretty excited about the breadth of topics that will be covered. -- Dear All, We are pleased to announce that our LSSTC workshop "Data Visualization and exploration in the LSST Era" will be held at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign from June 19 to June 21, 2018. The 3-day workshop is open to all interested attendees. However, preference will be given to early career scientists given the nature of the workshop format. Thanks to support from the LSST Enabling Science Group and NCSA we are glad to waive the registration fee and to provide some travel support. We welcome proposed contributions for short talks and 1 hour hands-on-tutorials on the topics listed on the website. The registration is now open and the deadline is June 1st, 2018. For more information please visit the workshop website at http://www.ncsa.illinois.edu/Conferences/LSST18/ We hope to see you there! On behalf of the SOC: Matias Carrasco Kind, University of Illinois at Urbana-Champaign Donna Cox, University of Illinois at Urbana-Champaign Leanne Guy, LSST Gilbert Holder, University of Illinois at Urbana-Champaign Xin Liu, University of Illinois at Urbana-Champaign Felipe Menanteau, University of Illinois at Urbana-Champaign William O'Mullane, LSST Laura Trouille, Adler Planetarium Matt Turk, University of Illinois at Urbana-Champaign

1 0

Request expedited review for PR 1741
by Nathan Goldbaum 30 Mar '18

30 Mar '18

Hi all, Currently the tests are failing on master due to my merging two pull requests yesterday that it turns out are mutually incompatible. My proposed fix is in PR 1741: https://github.com/yt-project/yt/pull/1741 Unfortunately the fix isn't trivial (unless I also back out PR 1693, which I'd prefer not to), so I'd really appreciate at least one or two other sets of eyes on the PR. I'd especially like to hear from people who have poked at the internals of yt's field and field detection system. -Nathan

1 0

Separate yt.units into its own package, unyt
by Nathan Goldbaum 29 Mar '18

29 Mar '18

Hi all, I had a request today to make yt.units its own package. Right now if someone wants to use yt.units in their own package, they need to depend on *all* of yt. That's quite a lot of code to depend on if all you want is an ndarray subclass that knows about units. From the beginning, I've tried to make yt.units *not* depend on the rest of yt as much as possible. For this reason it's relatively simple as far as code modifications go to extract yt.units into it's own package. This afternoon I've done most of that work and have created a new package called "unyt" (pronounced the same as unit). For now the code lives as a repo owned by my github account: https://github.com/ngoldbaum/unyt I'd like to create a new repository in the yt-project github organization named unyt as a place for this code to live: https://github.com/yt-project/unyt For now I'm *not* working towards making yt depend on unyt - effectively I've forked yt.units into a new package. I've attempted to keep the existing git history for the new package though, so you may find that you have commits in this new package that originated in yt. This *does* effectively double the maintenance burden for yt.units, since now I need to make sure that yt.units and unyt don't diverge too much. However, the pace of changes to yt.units is pretty slow these days so I'm not overly worried about creating a bunch of work for myself. Eventually we could consider making yt depend on unyt and making yt.units a compatibility shim, however I don't think we want to take that step yet. So far I've only made changes necessary to get unyt isolated from the rest of yt. I've also renamed a few things. For example, YTArray is now unyt_array and YTQuantity is now unyt_quantity. I'm curious whether anyone has a problem with creating a repo on the yt-project org for unyt to live in. If so, please let me know so we can hash it out. Please also let me know if you have any other questions or concerns about the course of action outlined above. -Nathan

7 7

fixing rockstar interface for python 3
by Britton Smith 27 Mar '18

27 Mar '18

Hi everyone, I'm trying to close out this bug: https://github.com/yt-project/yt_astro_analysis/issues/18 After spending a fair amount of time on this, all I've been able to determine is that the values of the server address and port seem to go missing for the server. These two values are passed from yt/analysis_modules/halo_finding/rockstar/rockstar.py to rockstar_interface.pyx in the same directory. They are then assigned to two global variables internal to Rockstar. Rockstar instances are either readers, writers, or servers. Both the readers and writers manage to hold on to the correct values for the server address and port, but when I check these values for the server itself, they are just empty strings. Somehow, this all works fine in python 2, i.e., all rockstar instances maintain the correct values. I am totally out of ideas for how to fix this. Does anyone have any thoughts? Britton

3 4

GSoc'18 Project Interpolation doubts
by Abhishek Singh 16 Mar '18

16 Mar '18

[cc'ing directly Nathan in case the mail gets stuck in Mailman] Hi Nathan, I started working on the proposal for the project idea *Interpolating particle data onto grids*. After, familiarizing myself with the background information that you pointed to, I have few doubts which are as follows: 1. The YTEP-32 and paper by Dan Price mention "scatter" approach for interpolation. I could not find any material on "gather" approach. Do you have anything handy in this regard? Or should I take the path of scatter approach and proceed further? 2. The project idea lists one of the deliverables as the ability to interpolate data onto a uniform resolution mesh. In YTEP-32 you have plotted slice and projection plots using octree and directly using particle data. Is my understanding correct? If we are able to plot the sph data with this particle-centric approach, then what is expected to be delivered with respect to this project idea. 3. The optional deliverables list the ability to interpolate particle data onto an octree mesh. Is this not the current approach (yt version 3.*)? If most of my understanding is not correct, I would love to clarify all these doubts as soon as possible, so that I work on the proposal. Thank you for your time! Best, Abhishek Singh

2 1

Jenkins down
by Nathan Goldbaum 16 Mar '18

16 Mar '18

Hi all, Kacper is currently fighting some fires with the Nebula cluster at NCSA. Until he's done Jenkins will be down. Please do not merge any PRs that have not passed the tests on Jenkins until it comes back up. Thank you for your patience, Nathan

2 2

FRB resolution and image shape
by Nathan Goldbaum 01 Mar '18

01 Mar '18

Hi all, Yi-Hao and I have been arguing in a pull request since this afternoon. I think we're having a tough time coming to an agreement about how to move this discussion forward so I thought I'd bring this discussion to the mailing list. For reference, this came up in PR 1710: https://github.com/yt-project/yt/pull/1710. I'm going to try to summarize the issue, my opinion, and YI-Hao's opinion. Yi-Hao, please let me know if you feel like I'm mischaracterizing your position. Our disagreement boils down to this test script: import yt import numpy as np arr = np.arange(8).reshape(4, 2, 1) data = dict(density=arr) ds = yt.load_uniform_grid(data, arr.shape) slc = ds.slice('z', 0.5) slc_frb = slc.to_frb(1, (4, 2)) dens_image = slc_frb['density'] print(dens_image.shape) print(dens_image) This script currently prints: (2, 4) [[ 0. 2. 4. 6.] [ 1. 3. 5. 7.]] g/cm**3 I think that the fact that the resolution argument of the to_frb call was (4, 2) means that I want an image with a shape (4, 2). But right now yt gives me an image with shape (2, 4). My pull request makes it so you get an image back with shape (4, 2). Yi-Hao correctly points out that the current behavior of yt gives a gives a pixelization that happens to exactly match the discretization of the data loaded into the yt dataset and he wants to keep that property. Unfortunately, with my pull request the same script would print: (4, 2) [[ 1. 5.] [ 1. 5.] [ 2. 6.] [ 2. 6.]] g/cm**3 So now the image's shape is correct, but the pixelization is no longer "natural" because this corresponds to 2 pixels along the x direction and 4 along y. I *can* get a "natural" pixelization if I tell yt to flip what it calls the "x" and "y" axes: ds.coordinates.x_axis[2] = 1 ds.coordinates.y_axis[2] = 0 If I add the above two lines to the script before calling to_frb, I get the following output: (4, 2) [[ 0. 1.] [ 2. 3.] [ 4. 5.] [ 6. 7.]] g/cm**3 This is again a "natural" pixelization because we have 4 pixels along y and 2 along x. However I don't think that's particularly useful since most people will want to make z-projections and slices with x plotted horizontally and y vertically. Unfortunately there's just a basic issue here with how to interpret the shape of an image geometrically on a plot. I have a feeling like Yi-Hao and I are a bit too close to this to resolve the issue either way. I'm hoping at least one person can weigh in with an opinion so we can find a way forward here. -Nathan

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev March 2018