New issue 599: Structured but irregular mesh
https://bitbucket.org/yt_analysis/yt/issue/599/structured-but-irregular-mesh
Matthew Turk:
We should be able to specify varying fwidths along an axis for a rectilinear grid. This will enable better handling of data like MOAB and weather simulations.
cc: @scopatz
Responsible: MatthewTurk
Hi all,
We're proud to release yt version 2.5.4. This is a scheduled point
release that includes all bug fixes identified and fixed since the
release of 2.5.3 on June 3.
Additions, changes and bug fixes include:
* Considerably (10x+) faster kD-tree building for volume rendering
* System build fix for POSIX systems
* Fixing domain offsets for halo centers-of-mass
* Removing some Enzo-specific terminology in the Halo Mass Function
* Addition of coordinate vectors on volume render
* Updating RADMC3D export code to support FLASH
* Pickling fix for extracted regions
* Addition of some tracer particle annotation functions
* Better error message for "yt" command
* Fix for radial vs poloidal fields
* Piernik 2D data handling fix
* Fixes for FLASH current redshift
If you are using the stable branch of yt from an installation script,
you can upgrade using "yt update" or "yt update --all" to upgrade your
full dependency stack. If you are using the development branch, you
may already have these fixes. A tarball of this release has been
uploaded to the Python Package Index (PyPI). While originally a 2.5.4
release was not planned, developments for 2.6 have been delayed. The
next scheduled release will be on August 1, and will be version 2.6.
We are hoping to include a unification of the Boxlib frontends,
compatibility with Python 3 (and embedding inside Blender) and other
usual improvements to the yt codebase.
Documentation for this release can be found at:
http://yt-project.org/docs/dev/
Thanks very much,
Matt, on behalf of the yt development team
Hi all,
I've just issued a big pull request that puts octrees (particle and
Eulerian) on a major diet. Comments, suggestions and test cases that
fail or pass would be welcomed!
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/54/octree-diet/diff
I've laid out how things are now done, and I'd also be grateful to
hear about whether those ideas should be changed/improved/etc.
-Matt
New issue 598: Particle fields should be created inside closures
https://bitbucket.org/yt_analysis/yt/issue/598/particle-fields-should-be-...
Matthew Turk:
Each particle field should be created inside a closure; none should exist in the primary namespace. This means that while accessing something like "ParticleMassMsun" will still be possible, it will map internally to always having "all","ParticleMassMsun". In doing so we'll ensure that at all times in the generation of the fields themselves, the particle types being requested are explicit; this will reduce or eliminate the guesswork necessary and simplify detection methods.
Responsible: MatthewTurk
