yt-dev November 2015

yt-dev@python.org

9 participants
24 discussions

by Erik Schnetter

Cactus multi-block data are topologically Cartesian, but each grid point's coordinate is arbitrary. - How would this best be handled? Should I create a UnstructuredIndex? Would "moab" be a good example to follow? - Is it possible to combine this with AMR? -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

5 years, 3 months

Parent and Children lists of AMRGridPatch

by Erik Schnetter

What do the Parent and Children lists for AMRGridPatch do in yt? I've set up a grid structure without defining these entries, and things seem to be working fine. Would yt automatically disable certain regions of the parents if there are overlapping children? In Cactus's AMR structure, a refined grid does not have a single parent grid -- it may overlap with multiple coarser grids. How do I tell yt about this? Do I need to split the fine grids? -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

5 years, 3 months

ANN: yt-3.2.2 release

by Nathan Goldbaum

We are proud to announce the release of yt 3.2.2! yt (http://yt-project.org) is an open-source, community-developed toolkit for analysis and visualization of volumetric data of all types, with a particular emphasis on astrophysical and nuclear engineering simulations. Version 3.2.2 is a regularly scheduled bugfix release including fixes for a number of issues reported since the release of yt 3.2.1. This release also supports matplotlib 1.5.x and NumPy 1.10.x. The changes in this version are summarized below and include a number of bugfixes, performance improvements, and documentation improvements. We urge all users of version 3.2 and 3.2.1 to upgrade to yt 3.2.2 immediately. Summary of changes ---------------------------- * Several fixes for units in the Tipsy frontend, including fixes for incorrect units when data were loaded without a parameter file available, support for Tipsy datasets converted from Gadget outputs, and support for tipsy auxiliary files containing data for more particles than the default chunking size. See PR 1668 <https://bitbucket.org/yt_analysis/yt/pull-requests/1668>, PR 1735 <https://bitbucket.org/yt_analysis/yt/pull-requests/1735>, and PR 1787 <https://bitbucket.org/yt_analysis/yt/pull-requests/1787>. * Added better documentation for answer testing. See PR 1742 <https://bitbucket.org/yt_analysis/yt/pull-requests/1742> and PR 1807 <https://bitbucket.org/yt_analysis/yt/pull-requests/1807>. * Fixed a typo in the particle filter documentation. See PR 1744 <https://bitbucket.org/yt_analysis/yt/pull-requests/1744>. * Avoid a test failure when running the unit tests in yt's default configuration. See PR 1754 <https://bitbucket.org/yt_analysis/yt/pull-requests/1754>. * Ensure grid patch objects have cell width metadata when needed. See PR 1756 <https://bitbucket.org/yt_analysis/yt/pull-requests/1756>. * Ensure matplotlib axes and figure objects are always valid when modifying a yt plot. See PR 1757 <http://17571668>. * Fix a bug in the ARTIO frontend's implementation of "ds.index.get_smallest_dx()". See PR 1759 <https://bitbucket.org/yt_analysis/yt/pull-requests/1759>. * Remove some dead code from the Chombo frontend. See PR 1761 <https://bitbucket.org/yt_analysis/yt/pull-requests/1761>. * Adapt to API change in matplotlib 1.5.x. See PR 1752 <https://bitbucket.org/yt_analysis/yt/pull-requests/1752>. * Use the effective redshift for calculating absorption spectra in the LightRay analysis module. See PR 1758 <https://bitbucket.org/yt_analysis/yt/pull-requests/1758> and PR 1783 <https://bitbucket.org/yt_analysis/yt/pull-requests/1783>. * Add support for more types of NMSU ART datasets. See PR 1764 <https://bitbucket.org/yt_analysis/yt/pull-requests/1764>. * Fix test failures under Numpy 1.10 or newer. See PR 1697 <https://bitbucket.org/yt_analysis/yt/pull-requests/1697>, PR 1767 <https://bitbucket.org/yt_analysis/yt/pull-requests/1767> and P <https://bitbucket.org/yt_analysis/yt/pull-requests/1779>R 1779 <https://bitbucket.org/yt_analysis/yt/pull-requests/1779>. * Avoid build failure in the check for openmp support. See PR 1768 <https://bitbucket.org/yt_analysis/yt/pull-requests/1768>. * Ensure field dependencies are resulved when creating a smoothed particle field. See PR 1772 <https://bitbucket.org/yt_analysis/yt/pull-requests/1758>. * Fix a bug in the chombo frontend that prevented loading data with more than 10 particle fields. See PR 1780 <https://bitbucket.org/yt_analysis/yt/pull-requests/1758>. * Minor performance optimization for the photon simulation analysis module. See PR 1766 <https://bitbucket.org/yt_analysis/yt/pull-requests/1766>. * Fix loading Athena data under python3 when parameters are provided at load time. See PR 1828 <https://bitbucket.org/yt_analysis/yt/pull-requests/1828>. * Ensure Athena datasets have a `velocity_unit` attribute. See PR 1831 <https://bitbucket.org/yt_analysis/yt/pull-requests/1831>. * Fix for loading GDF data in python3. See PR 1831 <https://bitbucket.org/yt_analysis/yt/pull-requests/1831>. * Speedup for unit operations. See PR 1782 <https://bitbucket.org/yt_analysis/yt/pull-requests/1782>. * Fix issues with SIMPUT files in the photon simulator analysis module. See PR 1790 <https://bitbucket.org/yt_analysis/yt/pull-requests/1790>. * Ensure the x and y limits of PhasePlot instances are controllable via set_xlim and set_ylim. See PR 1821 <https://bitbucket.org/yt_analysis/yt/pull-requests/1821>. * Fixing various issues in the Sunyaev-Zeldovich analysis module. See PR 1835 <https://bitbucket.org/yt_analysis/yt/pull-requests/1835>. * Stop referring to a requirements file in the installation docs. See PR 1839 <https://bitbucket.org/yt_analysis/yt/pull-requests/1839>. * Generate a nicer error message to work around bug in the nose testing framework. See PR 1840 <https://bitbucket.org/yt_analysis/yt/pull-requests/1840>. * Fix loading Gadget data in python3. See PR 1841 <https://bitbucket.org/yt_analysis/yt/pull-requests/1841>. * Fix loading Tipsy data in python3. See PR 1842 <https://bitbucket.org/yt_analysis/yt/pull-requests/1842>. * Pass bytes to FNV hashing algorithm, don't rely on python hashes. See PR 1845 <https://bitbucket.org/yt_analysis/yt/pull-requests/1845>. * Fix bug in ray "dts" and "t" fields. See PR 1846 <https://bitbucket.org/yt_analysis/yt/pull-requests/1846/bugfix-fixing-bug-i…> . * Make array_like_field return data with the same units as get_data. See PR 1847 <https://bitbucket.org/yt_analysis/yt/pull-requests/1847/bugfix-make-array_l…> . * Make default reult_id for parallel_objects more useful. See PR 1851 <https://bitbucket.org/yt_analysis/yt/pull-requests/1851/bugfix-make-default…> . * Update author name and e-mail metadata in setup.py. See PR 1854 <https://bitbucket.org/yt_analysis/yt/pull-requests/1854>. Coming Soon! ------------------- The next major release of yt will be version 3.3, which is slated to include an overhaul of the volume rendering system and support for analyzing and visualizing unstructured mesh data. Some of this functionality is already available on the development branch of yt. We welcome feedback from early testers. Standard Installation Methods ----------------------------- As with previous releases, you can install yt from source using one of the following methods. 1) From the install script (http://yt-project.org/#getyt ): If you previously installed yt from the install script, you can update your installation in-place using the following command: # Update $ yt update If you are on the “stable” branch, updating will bring you from yt 3.2.1 or 3.2 to 3.2.2, whereas if you are on the development “yt” branch, only the changes since your last update should be incorporated. To install from scratch, do the following: # Installation $ wget http://bitbucket.org/yt_analysis/yt/raw/stable/doc/install_script.sh $ bash install_script.sh 2) From pip (source or binary wheel, see below for more details): # Installation $ pip install yt # Update $ pip install -U yt 3) From the Anaconda Python Distribution (https://store.continuum.io/cshop/anaconda/): # Installation $ conda install yt # Update $ conda update yt Note that it might take up to a week for the conda package built by Continuum Analytics to be updated for yt 3.2.2. Installing Binary Packages via pip If you do not have compilers available, it is also possible to install binary packages (“wheels”) using pip on Windows and Mac OS X (64-bit only for both). This has the advantage of not needing to install yt from source using a proper compiler setup, which has caused occasional problems on both of these platforms and prevented us from installing yt easily on other Python distributions. Note that it may take several days for binary wheels for yt 3.2.2 to be uploaded. We have so far been able to install and run the binary distribution via pip on the following platforms and Python stacks: Note that it might take a day or two for the pip wheels to be updated. Windows x86_64: Enthought Canopy Python (https://www.enthought.com/products/canopy/) WinPython (http://winpython.sourceforge.net/) Mac OS X x86_64: Enthought Canopy Python (https://www.enthought.com/products/canopy/) Homebrew Python (http://brew.sh/) Python.org Python Mac OS X’s system Python MacPorts Python (https://www.macports.org/) This is somewhat experimental, so other distributions may work (or not), please submit bug reports or successes to the mailing list or to the Bitbucket issues page (http://bitbucket.org/yt_analysis/yt/issues). Both Python 2.7 and Python 3.4 are supported. The dependencies for installing yt via this method are the same as from source: NumPy h5py HDF5 SymPy Matplotlib IPython (not required, but strongly recommended) To install a new version of yt on one of these platforms, simply do $ pip install yt and you should get the binary distribution automatically. Also, if your python installation is system-wide (e.g., the Mac system Python) you might need to run pip with administrator privileges. For more information, including more installation instructions, links to community resources, and information on contributing to yt’s development, please see the yt homepage at http://yt-project.org and the documentation for yt- 3.2.2 at http://yt-project.org/doc. yt is the product of a large community of developers and users and we are extraordinarily grateful for and proud of their contributions. Please forward this announcement on to any interested parties. As always, if you have any questions, concerns, or run into any trouble updating please don't hesitate to send a message to the mailing list or stop by our IRC channel. All the best, Nathan Goldbaum, on behalf of the yt development team

5 years, 3 months

yt 3.2.2 is going to be released soon

by Nathan Goldbaum

I'll be backporting bugfixes to stable and doing a 3.2.2 release in the next few days. If you want to have bugfixes included in this release, please try and have them ready in the next couple of days. Nathan

5 years, 3 months

Issue #1143: Sphere callback for OffAxisProjectionPlot does not do coordinate conversions correctly (yt_analysis/yt)

by Nathan Goldbaum

New issue 1143: Sphere callback for OffAxisProjectionPlot does not do coordinate conversions correctly https://bitbucket.org/yt_analysis/yt/issues/1143/sphere-callback-for-offaxi… Nathan Goldbaum: The following test script: ``` #!python import yt ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') plot = yt.OffAxisProjectionPlot(ds, [0, 0, 1], 'density') plot.annotate_sphere([0, 0, 0], (300, 'kpc')) ``` Produces the following image: ![download.png](https://bitbucket.org/repo/BXbAb/images/2406981540-download.png) This is wrong, the circle should be centered on the origin.

5 years, 3 months

Vertex-centred AMR data?

by Erik Schnetter

I have implemented a front-end for cell-centred Cactus AMR data. However, many Cactus simulations use vertex-centred AMR. That is, data is stored at the vertices of a grid (not in the cells), and coarse vertices are at the same locations as fine vertices. How do I present such data to yt? Do I need to set grid coordinates differently, or is there a "vertex centred" flag? When vertex-centred data are displayed, then I expect either a "control volume" around each vertex to have the same value, or to use e.g. linear interpolation in the cells from the respective boundaries. -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

5 years, 3 months

Volume rendering refactor now available in dev branch

by Cameron Hummels

Hey yt community, Over the last two years, there has been an ongoing effort led by Sam Skillman to refactor the volume rendering (VR) code for making volumetric images using radiative transfer models on simulation outputs. Because it's such a large functional change to the codebase, all of these commits have been kept in the `experimental` head on the dev branch of yt up until now. A month ago, there was a code sprint at SLAC where Matt, Nathan, Suoqing, Andrew, Kacper, Ji-hoon, Sam, and I worked hard in getting the new VR code ready for release to the larger community. While this code still needs work before it can go into the next stable version of yt (3.3), we've now merged the code into the main development head, and we invite users to try out this functionality to see how well it works for their own datasets. For a full description of the new volume rendering interface and how to use it, please see the narrative docs, new cookbook recipes, and annotated example. For more background on where we'd like this functionality to go in the future, see the YTEP. VR Docs: http://yt-project.org/docs/dev/visualizing/volume_rendering.html Cookbook (search for Volume Rendering): http://yt-project.org/docs/dev/cookbook/index.html Annotated Example of VR usage: http://yt-project.org/docs/dev/visualizing/volume_rendering_tutorial.html VR YTEP: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0010.html To get access to this new VR functionality, you have to be on the development (ie "yt") branch and using the most recent changeset (ie "tip"). For information on how to switch branches, see: http://yt-project.org/docs/dev/installing.html#switching-versions-of-yt-yt-… . If you wish to continue to use the old VR interface, it will remain available in the yt/visualization/volume_rendering/old_camera.py file. Thanks to all of the hard work by the developers who helped get this out! Cameron -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org

5 years, 3 months

PR triage hangout

by Nathan Goldbaum

Hi all, I just created the google+ event for the PR triage hangout today: https://plus.google.com/events/cvmpp3ma58dc8trsn2nddddt8ls?authkey=CKf9uYmX… Sorry for the late notice! It will be today at 1:00 PM. Also next week is supercomputing, so I and maybe Matt likely won't be able to attend. -Nathan

5 years, 3 months

Adopting a code of conduct

by Nathan Goldbaum

Hi all, I'd like to start the ball rolling on instituting a code of conduct for the yt community. This will be added as a YTEP, linked from the "community" portion of the webpage, and added the the yt repository. Having a code of conduct is important because it the community norms we abide by very concrete. It also affirms our commitment to embracing diversity, openness, respect, and collegiality in our interactions. I think officially adopting a code of conduct also lowers the barrier to entry for new contributors who might be scared off based on preconceived notions about open source projects (e.g. the Linux kernel). I think a good place to start would be to use the Python Software Foundation's code of conduct and just replace "Python" with "The yt Project". I really like the PSF code of conduct and feel that it does a good job of describing how we conduct business already. I'm curious whether this is amenable to everyone. Are there other CoC documents that we should look at? Are there additional points we should add to or elide from the PSF CoC to make it more fitting for yt? Thanks for your input! -Nathan

5 years, 3 months

Few questions about YT

by Tomer Nussbaum

Hey guys, I continue to work on the 3D thing, and I have a few questions, it would be *super helpful *if you can answer me, even for some of my questions. So if you even have a hint I would like to hear about it. Thats what I have now: ART example <https://sketchfab.com/models/d267102434274bdbb5f75f5b9ef27b44>, so with some help I might succeed. Thanx, Tomer 0. What is the main reason that _extract_isocontours_from_grid doesn't work on ART? is it just not implemented? is there another big problem beneath it? is it related to KDTree? How come ENZO work and ART doesn't? 1. What is the ghost zones idea? does it work on ENZO? does it work on ART OcTree data? 2. Can ghost_zone_interpolate work on OcTree? on OctreeSubsetBlockSlice? 3. In get_vertex_centered_data, it gets from ENZO 6X6X6 data blocks, is it true that one of the differences between ENZO and ART, is that the adaptive mesh of Art is divided to 2X2X2 but ENZO has 6X6X6? The code I look at is in "construction_data_containers.py" YTSurfaceBase.get_data(..) function line 1031: for block, mask in self.data_source.blocks: 4. What is main idea of the classes AMRGridPatch(YTSelectionContainer), OctreeSubsetBlockSlice(object), OctreeSubset(YTSelectionContainer)? what is the difference between them? doesn't OctreeSubsetBlockSlice supposed to inherite OctreeSubset? while calling self.data_source.blocks for ENZO I get AMRGridPatch and for ART I get OctreeSubsetBlockSlice. but AMRGridPatch inherits from YTSelectionContainer as OctreeSubset. different to OctreeSubsetBlockSlice which inherits from object... The code I look at is in "construction_data_containers.py" YTSurfaceBase.get_data(..) function line 1031: for block, mask in self.data_source.blocks:

5 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev November 2015