yt-dev July 2014

yt-dev@python.org

16 participants
70 discussions

GDF PR--call for some feedback
by John Zuhone 22 Sep '14

22 Sep '14

Hi all, I have a work-in-progress PR in the hopper regarding GDF reading and writing: https://bitbucket.org/yt_analysis/yt/pull-request/1001/wip-some-gdf-writing… What it does is implement direct writing of covering grids to GDF files (something I've been using in my research, to work with the resulting files directly in yt) and clobbering existing files with the same path if the user allows for it. However, when fiddling around with this I determined that it was necessary to make GDF more unit-aware. Ultimately, I determined that changes were needed that would break the standard that we had determined for the files (http://yt-project.org/gdf.txt). The two main changes are: 1) Remove "field_to_cgs", and allow the fields to be in whatever units we wish them to be in the file (which are specified as HDF5 attributes). 2) Add a new top-level group containing the information for "length","mass", and "time" units. These will be used when the file is opened up in yt to determine the units. Since (for now) we do automatic conversion to cgs, that is something that is still left unimplemented, but otherwise I think this is all to do for now. I'm writing the email in case anyone has any suggestions or objections to the format changes--particularly Jeff or Kacper. We'll obviously need to document them if they are accepted. Best, John -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone(a)gmail.com john.zuhone(a)nasa.gov

8 9

volume rendering orientation
by Michael Zingale 31 Jul '14

31 Jul '14

To help with understanding the volume rendering orientation issues, here's a self-contained test that I've been using. This puts a single cube on +x, two cubes on +y, and three cubes on +z. North is set to +z. The save_annotated image has the right orientation and handedness. The write_png image is upside down. I found this data very helpful in understanding and testing orientations. Mike ------ import pylab import yt import numpy as np N = 128 xmin = ymin = zmin = -1.0 xmax = ymax = zmax = 1.0 arr = np.zeros((N,N,N), dtype=np.float64) arr[:,:,:] = 1.e-4 bbox = np.array([ [xmin, xmax], [ymin, ymax], [zmin, zmax] ]) # coordinates -- in the notation data[i, j, k] x = (np.arange(N) + 0.5)*(xmax - xmin)/N + xmin y = (np.arange(N) + 0.5)*(ymax - ymin)/N + ymin z = (np.arange(N) + 0.5)*(zmax - zmin)/N + zmin x3d, y3d, z3d = np.meshgrid(x, y, z, indexing="ij") # single cube on +x xc = 0.75 dx = 0.05 idx = np.logical_and(np.logical_and(x3d > xc-dx, x3d < xc+dx), np.logical_and(np.logical_and(y3d > -dx, y3d < dx), np.logical_and(z3d > -dx, z3d < dx)) ) arr[idx] = 1.0 # two cubes on +y dy = 0.05 for yc in [0.65, 0.85]: idx = np.logical_and(np.logical_and(y3d > yc-dy, y3d < yc+dy), np.logical_and(np.logical_and(x3d > -dy, x3d < dy), np.logical_and(z3d > -dy, z3d < dy)) ) arr[idx] = 0.8 # three cubes on +z dz = 0.05 for zc in [0.5, 0.7, 0.9]: idx = np.logical_and(np.logical_and(z3d > zc-dz, z3d < zc+dz), np.logical_and(np.logical_and(x3d > -dz, x3d < dz), np.logical_and(y3d > -dz, y3d < dz)) ) arr[idx] = 0.6 data = dict(Density = arr) ds = yt.load_uniform_grid(data, arr.shape, bbox=bbox) import yt.visualization.volume_rendering.api as vr c = np.array([0, 0, 0]) L = np.array([1.0, 1.0, 1.0]) W = 2.0*ds.domain_width N = 720 north = np.array([0, 0, 1]) tf = vr.ColorTransferFunction((0.1,1.0)) tf.sample_colormap(1.0, 0.05, colormap="coolwarm") tf.sample_colormap(0.8, 0.05, colormap="coolwarm") tf.sample_colormap(0.6, 0.05, colormap="coolwarm") cam = vr.Camera(c, L, W, N, transfer_function=tf, north_vector = north, ds=ds, fields=[('gas', 'Density')], log_fields=[False]) im = cam.snapshot() nim = cam.draw_domain(im) nim.write_png("test.png") cam.save_annotated("test_annotated.png", nim) ------ -- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

2 2

Issue #873: volume rendering set_background does not work (yt_analysis/yt)
by Cameron Hummels 31 Jul '14

31 Jul '14

New issue 873: volume rendering set_background does not work https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgro… Cameron Hummels: I tried to make a VR with different background colors by combining the two cookbook recipes: http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgro… http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume… The resulting script is here: http://paste.yt-project.org/show/4978/ Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background. When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization. I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.

4 4

yt mapserver
by Cameron Hummels 30 Jul '14

30 Jul '14

Does anyone know what happened to the mapserver in 3.0? It is no longer in command_line.py, and the docs are in conflict about it working. I'll fix this, but I wanted to know if it had been removed on purpose. -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

3 3

3.0 release
by Matthew Turk 30 Jul '14

30 Jul '14

Hi all, Thank you to everybody for pushing *so hard* on everything the last few days. I have now finished up the drafts of my remaining contributions to the documentation, which I *believe* is the last remaining area of focus. I would like to take Cameron up on his offer, which I previously voted again, to delay until Friday. This is not so that we can all keep working, but because *I* misjudged the level of my contributions and what they would require, and *I* need a few days to let them settle. Mea culpa. Cameron, Nathan, Britton, Mike, Hilary, Aaron -- everyone has just been absolutely amazing. So I will be submitting mine, they can get reviewed over the next couple days, and then on Friday maybe we can "release" it? Does that work? -Matt

3 5

Thanks for the hard work on the docs
by Nathan Goldbaum 30 Jul '14

30 Jul '14

I'm looking over the docs right now and am blown away by the significant improvement relative to the situation the docs were in before the push. Thank you so much everyone who has contributed to this push. There is still some room for proofreading, so please take a look at the docs if you have some free time today. -Nathan

1 0

Organizational Issues with Docs
by Cameron Hummels 30 Jul '14

30 Jul '14

Hey peeps, Right now there is inconsistency in the docs of using YT, ``yt`` (i.e. code-text) or yt. What do people prefer here? I think we should avoid YT, but I could go either way on the remaining two options. Also, section headers are of two formats: "Capitalize all Important Words" and "Only capitalize the first word of the section". I'm more of a +1 on the first option. There is a suggestion made by Michael Zingale about moving the parallel docs from the analysis section to being a top-level section in the docs, since it applies to viz, analysis, etc. I'm -1 on this move as I like having the top-level docs be relatively few in number. Lastly, there is no real "introduction" as to what the different sections mean. There is the bootcamp and cookbook which give lots of usage examples, but no true introduction that tells people why to look at "fields" or "objects" or whatever. We have tried to lay out the docs in an order and with labels that is logical and gives people an idea of their contents, but does anyone think we should have a short top-level introduction? Or even something on the front page? Not sure on this, but new users might have more of an opinion. Keep up the good work! Cameron -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

3 4

comment on cookbook
by Michael Zingale 29 Jul '14

29 Jul '14

I'm looking over the cookbook docs and trying the recipes on my own dataset in prep for the release. I don't really understand the "Image Background Colors" recipe at the end of: http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html This just shows various gradients, but is the purpose to show that one can plot their data over one of these gradients? If so, perhaps we can add some data to one of these? Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

1 0

answer testing in parallel
by Britton Smith 29 Jul '14

29 Jul '14

Hi all, Does anyone, perhaps Kacper, know if we can do any answer testing in parallel? I would like to add a test for the rockstar halo finder, but it has to be run with a minimum of 3 MPI tasks. This would not require 3 actual CPUs to run on since each the tasks sort of take turns. Is there a way to do this? Thanks! Britton

2 2

3.0 release delay
by Cameron Hummels 29 Jul '14

29 Jul '14

Hello, First I want to thank everyone for their hard work at getting 3.0 where it is in terms of functionality, bug fixes, and documentation. However, I'm concerned that there are still several things that need doing in the documentation prior to release of 3.0. https://trello.com/b/Y5XV4Hod/yt-3-0 Beyond that, I think once those things are done, we need some proofreading of the docs, because I'm not convinced there aren't still sections that are out of date and reflecting 2.x versions of the code. Proofreading (and subsequent correction) may take a while. I think it behooves us to push back the release a few more days until we make sure this is where we want it to be. This is a major release with major API breakages, and I want to make sure the documentation actually reflects the codebase, so new users and new converts to 3.0 don't get confused. I certainly was confused when i first moved over because there are a lot of significant changes that it's easy to forget after using it for a while and being as tied into the community as we all are. What do people think? Cameron -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

6 13

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev July 2014