yt-dev December 2016

yt-dev@python.org

11 participants
14 discussions

Testing infra is currently down
by Kacper Kowalik 04 Jan '17

04 Jan '17

Hi all, we had a hdd failure on a machine hosting yt's jenkins and blog instances. PRs are not being tested at the moment. I don't have an ETA for a replacement yet. I will keep you posted. Cheers, Kacper

5 5

Why does ProjectionPlot not take and pass **kwargs
by Yi-Hao Chen 21 Dec '16

21 Dec '16

Hi all, I am wondering why ProjectionPlot (and others) do not take all the keyword arguments and pass them to PWViewerMPL and PlotWindow. For example, currently there is no way to set buff_size at the creation of a plot. One has to call .set_buff_size after the plot was created. I am thinking about leaving only the arguments specific to ProjectionPlot explicitly, and use **kwargs to pass all other arguments to PlotWindow. But if there are reasons not to do this, please let me know. Thanks! Yi-Hao

2 6

Implementing new Difference Plots
by Matthew Krafczyk 20 Dec '16

20 Dec '16

Hi folks, I'm currently working on implementing a couple of plots to help investigate differences between two similar datasets. I've implemented DifferenceProjectionPlot, RelativeDifferenceProjectionPlot, and AsymmetryProjectionPlot. These are available at my fork of yt https://bitbucket.org/krafczyk/yt under the bookmark 'features/difference_plot'. Essentially, Each of these Plots is a subclass of PWViewerMPL like ProjectionPlot, but create's it's FRB by first creating FRBs for the two data sets then applying an operation to each pixel value to get a new derived value which is a part of the new FRB. For DifferenceProjectionPlot this is simply A-B For RelativeDifferenceProjectionPlot this is (A-B)/A For AsymmetryProjectionPlot this is (A-B)/(A+B) It's already been suggested to me that I can avoid creating three new classes by moving the choice of combination algorithm to a keyword argument, but I'd like to hear more suggestions. Thanks, Matthew Krafczyk

2 1

Issue #1304: Boolean objects only inherit the fields present in both of their parent objects (yt_analysis/yt)
by chummels 20 Dec '16

20 Dec '16

New issue 1304: Boolean objects only inherit the fields present in both of their parent objects https://bitbucket.org/yt_analysis/yt/issues/1304/boolean-objects-only-inher… chummels: Boolean objects are meant to combine the fields present in two data objects from the same dataset. Normally, this means that they will have the same fields present. However, the `ray` object creates a special field `"t"` as a parametric variable to tell you how far along the ray you are (goes from 0 to 1). When I take an intersection of this `ray` object with a `region` object, the result lacks this `"t"` field because `"t"` is only present in a single parent in the boolean intersection. Here is an example of this in action with a sample dataset: import yt import numpy as np ds = yt.load("gizmo_cosmology_plus/snap_N128L16_151.hdf5") ad = ds.all_data() ad[('gas', 'temperature')] ray_start = ds.arr(np.random.random(3), 'unitary') ray_end = ds.arr(np.random.random(3), 'unitary') ray1 = ds.ray(ray_start, ray_end) ray2 = ray1 & ad # ray1 object *has* a t field because it was created from scratch print ray1['t'] # ray2 object *lacks* a t field because only one of its parents contains it print ray2['t']

1 0

Issue #1303: Boolean Containers only work for 3D objects (yt_analysis/yt)
by chummels 20 Dec '16

20 Dec '16

New issue 1303: Boolean Containers only work for 3D objects https://bitbucket.org/yt_analysis/yt/issues/1303/boolean-containers-only-wo… chummels: In trying to create the intersection of a `Ray` and a `Region` object, yt fails because Boolean operations only exist for 3D selection data containers. It seems like it should work for 1D or 2D data containers with 3D datasets too, but maybe this is harder than I am imagining.

1 0

Refactor particle dataset
by Bili Dong 14 Dec '16

14 Dec '16

Hi Everyone, I’m bugging the mailing list to gather opinions from anyone interested the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-partic…> I’m working. The purpose of the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-partic…> is to refactor the `ParticleDataset` class in yt. Currently the `ParticleDataset` is not much different from `Dataset`, but there sure are common attributes and methods specific to particle datasets that should be put in the `ParticleDataset` class. To make particle dataset better supported in yt, I plan to do the following things: - Move particle specific operations from `Dataset` to `ParticleDataset`. - Add some particle dataset specific properties. - Gather common operations from `ParticleDataset`’s direct inheritance to `ParticleDataset` itself. Currently there are common parts in `TipsyDataset` and `GadgetDataset`’s constructor that I have figured out. There might be more. - As Nathan suggested, it might be good to have an `SPHParticleDataset` for SPH codes but `ParticleDataset` for pure N-body codes. If you’re interested in any of these, or have any idea to add, please feel free to leave your comments here or in the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-partic…>. Thanks, Bili

1 0

ANN: yt 3.3.3 release
by Cameron Hummels 12 Dec '16

12 Dec '16

We are proud to announce the release of yt 3.3.3! Version 3.3.3 is a regularly scheduled bugfix release including fixes for a number of issues reported since the release of yt 3.3.2. 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 managed via pip, update following: $ pip install -U yt Finally, if you manage your yt installation by running out of a clone of the yt mercurial repository, update following: $ yt update We would like to thank the following people for their contributions to this release: Nathan Goldbaum Cameron Hummels Ben Keller Kacper Kowalik Jonah Miller Andrew Myers Hsi-Yu Schive Britton Smith Matthew Turk John Wise John ZuHone A summary of changes in this release, along with the number of the pull request implementing the change follows below: Additional docstrings for unstructured mesh data. See PR 2403 <https://bitbucket.org/yt_analysis/yt/pull-requests/2403/some-hopefully-illu…> . Speedup in clump finding. See PR 2426 <https://bitbucket.org/yt_analysis/yt/pull-requests/2426/opt-typedef-array-r…> . Speedup in tests. See PR 2427 <https://bitbucket.org/yt_analysis/yt/pull-requests/2427/use-slighlty-smalle…> . Bugfixes and docs for Tipsy data. PR 2430 <https://bitbucket.org/yt_analysis/yt/pull-requests/2430/tipsy-correct-auxil…> , PR 2431 <https://bitbucket.org/yt_analysis/yt/pull-requests/2431/clarify-the-use-of-…> . Bugfix in Ramses time calculation. PR 2433 <https://bitbucket.org/yt_analysis/yt/pull-requests/2433/bugfix-explicitly-u…> . Bugfix in octree indexing. PR 2434 <https://bitbucket.org/yt_analysis/yt/pull-requests/2434/bugfix-explicitly-u…> . Fixing behavior of ProfilePlots and Profiles PR 2437 <https://bitbucket.org/yt_analysis/yt/pull-requests/2437/bugfix-fix-rich-dis…> , PR 2448 <https://bitbucket.org/yt_analysis/yt/pull-requests/2448/bugfix-more-careful…> . Bugfix for EPSWritter handing dicts in PlotsWindow instances. PR 2440 <https://bitbucket.org/yt_analysis/yt/pull-requests/2440/updating-eps_writer…> . Ensuring ion fields utilize dataset's metal-specific fields PR 2442 <https://bitbucket.org/yt_analysis/yt/pull-requests/2442/making-nuclei-densi…> . Assure no orphaned mercurial processes PR 2449 <https://bitbucket.org/yt_analysis/yt/pull-requests/2449/interact-with-mercu…> . Adding checks for bad values in AbsorptionSpectrum PR 2450 <https://bitbucket.org/yt_analysis/yt/pull-requests/2450/adding-check-for-ne…> . Bugfix in geographic handler PR 2452 <https://bitbucket.org/yt_analysis/yt/pull-requests/2452/fixing-x-y-axis-con…> . Bringing gadget data more inline with other SPH datasets PR 2456 <https://bitbucket.org/yt_analysis/yt/pull-requests/2456/enabling-gadget-fro…> , PR 2436 <https://bitbucket.org/yt_analysis/yt/pull-requests/2436/bugfix-use-integer-…> . Bugfix when OpenMP unavailable PR 2458 <https://bitbucket.org/yt_analysis/yt/pull-requests/2458>. Enable light_ray_solution saved to actual LightRay class PR 2460 <https://bitbucket.org/yt_analysis/yt/pull-requests/2460/save-light-ray-solu…> . Assure path uses dataset's own unit system. PR 2462 <https://bitbucket.org/yt_analysis/yt/pull-requests/2462/path-unit-should-us…> . Cameron Hummels, On behalf of the yt development team -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org

1 0

Imminent yt 3.3.3 stable bugfix release
by Cameron Hummels 11 Dec '16

11 Dec '16

Hey everyone, I've put together a PR of backported bugfixes for an upcoming yt 3.3.3 release. Feel free to glance it over and give comments. The PR includes a couple dozen bugfixes merged over the last 1.5 months since our last bugfix release. It passes all the unit tests in py2 and py3, but fails several answer tests simply because of misalignment between the stable and dev api. I was hoping to get this merged rather quickly so we can put out the release in the next day or so. This will be the stable version of yt that trident builds off of, and we're putting out the trident method paper on the arxiv this week with our first 1.0 release of the code. Let me know if you have any questions or comments. https://bitbucket.org/yt_analysis/yt/pull-requests/2470/backport-bugfixes-f… Cameron -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org

1 0

Issue #1302: `take_log` works on generic field name, but not front end name (yt_analysis/yt)
by Michael Zingale 09 Dec '16

09 Dec '16

New issue 1302: `take_log` works on generic field name, but not front end name https://bitbucket.org/yt_analysis/yt/issues/1302/take_log-works-on-generic-… Michael Zingale: This script reads in a Castro (boxlib) file and makes two plots. The goal is to not take the log. For the first attempt, we disable log using the field `('boxlib', 'density')`. For the next, we use `('gas', 'density'). Note these are ailased to one another as the print shows: ``` On-Disk Field (boxlib, density): (units: g/cm**3, display_name: '\rho') Alias Field for "('boxlib', 'density')" (gas, density): (units: g/cm**3, display_name: '\rho') ``` but only the one with `gas` successfully disables the log. ``` import yt ds = yt.load("plt00000") print(ds.fields.boxlib.density) print(ds.fields.gas.density) ds.index ds.field_info['boxlib','density'].take_log = False p = yt.SlicePlot(ds,"theta",'density') p.save("densBoxLib.png") ds = yt.load("plt00000") ds.index ds.field_info['gas','density'].take_log = False p = yt.SlicePlot(ds,"theta", 'density') p.save("densGas.png") ``` The test dataset is here: http://bender.astro.sunysb.edu/random/plt00000.tgz (for some reason, I can no longer open the datasets on the yt page, so something changed in the front end that I need to investigate separately, and/or, update the sample datasets)

1 0

Re: [yt-dev] Soliciting opinions about how to handle data tables for spectral integrator port
by Matthew Turk 08 Dec '16

08 Dec '16

Hi, I'm okay with this, but let's try to make it obvious where things go. (which you have all suggested.) I think astropy does this and has helper functions for it. Matt On Dec 8, 2016 9:28 AM, "Britton Smith" <brittonsmith(a)gmail.com> wrote: HI all, I agree that it would be best to keep the data files out of the repo. What about adding some config variables to control where the data gets stored? We could even have it default to storing things in .config/yt. Perhaps, on the first import when the data is not there, you just get a notice with links to wget/curl them. Britton On Wed, Dec 7, 2016 at 12:12 PM, Nathan Goldbaum <nathan12343(a)gmail.com> wrote: > > > On Wed, Dec 7, 2016 at 1:30 PM, John Zuhone <jzuhone(a)gmail.com> wrote: > >> Hi everyone, >> >> I just issued PR 2465 (https://bitbucket.org/yt_anal >> ysis/yt/pull-requests/2465/wip-port-the-spectral_integrator-analysis/) >> to port the spectral integrator analysis module (originally written by >> Britton) under yt.fields. spectral_integrator is an analysis module that >> creates X-ray emission fields in user-specified energy bands. >> >> The hitch is that spectral_integrator uses HDF5 tables to compute the >> emissivity, since they are not analytical functions. We currently host >> those tables on yt-project.org/data. spectral_integrator downloads them >> automatically if the analysis module is used and they are not present. >> >> There was some discussion on Slack as to whether or not this is the >> correct approach, since it’s not ideal for certain computing environments >> (e.g., HPC). >> > > Also a problem for e.g. packaging yt on linux distros. > > >> The files are a total of about 2.4 MB in size, so there is some reticence >> to bundling them with yt. >> > > So my main concern here is adding them to the repo. If you could figure > out a way to add them to the source distribution without including them in > the repo (and then issue an error with a URL for non-sdist builds of yt > [e.g. from the repo]), it wouldn't be a problem. > > This isn't really a generic solution for all binary files we might want to > send to users, but 2.4 MB isn't all that big to be part of an sdist or > wheel. > > >> There is also the issue that uploading new versions of the tables breaks >> backward-compatibility. I have sacrificed backwards-compatiblity for >> considerable simplification of code. >> > > I think the solution is just to use different names for the files or the > hdf5 datasets or groups here so the code can tell the difference. > > >> >> Does anyone have any ideas about the best way to handle this issue? >> >> Best, >> >> John Z >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> > > _______________________________________________ > yt-dev mailing list > yt-dev(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev December 2016