Hi all,
I wanted to write with a brief update on a few things. Now that
yt-3.0 has been released, we have changed the way named branches work
in the yt repository.
* yt-2.x => This is what used to be the "yt" branch, and is legacy yt
2.x support.
* yt-3.0 => This branch is deprecated, but not closed, and will not
be undergoing regular updates
* yt => This is the new development branch, which is now "yt 3.0"
This will become yt 3.1.
* stable => This is the stable branch (as before) which now
corresponds to yt-3.0 stable releases.
If you do not use the "yt update" functionality, you may disregard the
remainder of this email.
If you have been running yt 2.x, and want to stay on yt 2.x, you will
need to make a one-time modification to your source directory. NOTE :
ANY UNCOMMITTED CHANGES WILL BE WIPED OUT BY THIS COMMAND.
1) Activate your yt environment (typically via the activate script)
2) cd $YT_DEST/src/yt-hg
3) hg pull
4) hg up -C yt-2.x
That will switch you to the yt-2.x branch.
If you have been running yt 3.0, you will need to make a similar modification:
1) Activate your yt environment (typically via the activate script)
2) cd $YT_DEST/src/yt-hg
3) hg pull
4) hg up -C yt
Hope that helps!
-Matt
Hi all,
Congrats to everyone on a successful release of yt 3.0!
I wanted to drop the developers a line and get some opinions and feedback on a software package I'd like to release in the next week or so. It's called "jt".
jt is a wrapper for yt for the Julia programming language. Julia is a new(-ish) high-level, high-performance dynamic programming language for technical computing. If you want to learn more about Julia, visit http://julialang.org. One of the most important things to note about Julia is that it has a "just-in-time" compiler, so it can be very fast (within a factor of few of C speed in some cases). There is also a lot of interoperability between Julia and Python, including wrappers for Matplotlib and Sympy, and even an extension of the IPython (soon to be Jupyter) notebook!
A short summary of what jt exposes from yt in Julia:
* Datasets
* Some data objects (e.g., spheres, rectangular regions, slices, projections, profiles, etc.)
* YTArrays and YTQuantities
* Simple visualization tools (e.g., SlicePlot, ProjectionPlot, FixedResolutionBuffer)
Here's why I'm mailing the dev list about this. I want jt to be an expansion of yt's capabilities into another programming language, particularly a new one like Julia which is proving popular for scientific computing. I also, however, want to be sensitive to concerns that jt could detract from yt, or become something else that we need to support that we don't really have the time or resources for. So, let me be clear about a couple of things:
1. No one should be expected to support this software but me, unless any of you want to join in. I do not want questions about it to be handled on the yt-users list, for example. I haven't decided how questions about it should be handled, except that for now they should just be directed to me. I doubt there will ever be enough people using it that there would be a need for it to have its own list.
2. I do not want jt to be a distraction from yt, since:
a) it requires yt to work
b) it exposes a small subset of everything yt does
Most of my work is still going to be in Python/yt, but I thought this would be a fun project, useful for myself and others, and a good way to learn a new language. I wanted to strike a balance between making jt a part of yt itself (which would make Julia a dependency of yt, soft or hard, which we do not want), and designing a whole new package in Julia from scratch to do exactly what yt does, which seems like a pointless reinventing of the wheel.
These are probably obvious points, but I wanted to make sure I got them across. I wanted you all to have a chance to have a look at my code and documentation if you wanted (links below), and then give me some feedback. In particular, I'd like to hear from anyone that has any of the concerns I mentioned above (or others).
I'd like to make a release in about a week, so I'll wait for about that long on feedback.
Thanks all!
John Z
Some helpful links:
jt source: http://github.com/jzuhone/jt
jt Documentation: http://www.jzuhone.com/jt
Dear yt developers,
> From: Matthew Turk <matthewturk(a)gmail.com>
> Date: Mon, Aug 4, 2014 at 9:50 AM
> Subject: [yt-users] ANN: yt-3.0 released!
>
> The yt community is proud to announce the release of yt 3.0.
I write you on the behalf of the Debian Astronomy working group. We are
trying to package and maintain astronomy related software for the
Debian/GNU operating system.
After getting your yt-3.0 announcement, I found your web site [1], and I
think that this projects would be worth to be packaged for Debian.
Would you like to join our efforts by packaging your software? We can
offer any help in case you run into difficulties or have questions. You
can contact me directly, and/or (preferably) subscribe to our mailing
list [2].
I found an older question on yt-users [3] about a possible Ubuntu ppa --
since Ubuntu (and other distributions, like Mint) takes most of the
packages directly from Debian, it would automatically be there as well.
And since (as mentioned in an answer to [2]) the installation procedure
is clean, the packaging would be quite easy, but with some advantages
for the user (like automated upgrades).
Best regards
Ole
[1] http://yt-project.org/
[2] https://lists.debian.org/debian-astro/
[3]
http://lists.spacepope.org/htdig.cgi/yt-users-spacepope.org/2012-March/00...
A HUGE Congratulations to the entire yt-dev team and community!
Be Well
Anthony
On Mon, Aug 4, 2014 at 9:50 AM, Matthew Turk <matthewturk(a)gmail.com> wrote:
> The yt community is proud to announce the release of yt 3.0.
>
> 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 simulations and
> nuclear engineering simulations.
>
> This release of yt features an entirely rewritten infrastructure for
> data ingestion, indexing, and representation. While past versions of
> yt were focused on analysis and visualization of data structured as
> regular grids, this release features full support for particle
> (discrete point) data such as N-body and SPH data, irregular
> hexahedral mesh data, and data organized via octrees. This
> infrastructure will be extended in future versions for high-fidelity
> representation of unstructured mesh datasets.
>
> Highlighted changes in yt 3.0:
>
> * Units now permeate the code base, enabling self-consistent unit
> transformations of all arrays and quantities returned by yt.
> * Particle data is now supported using a lightweight octree. SPH
> data can be smoothed onto an adaptively-defined mesh using standard
> SPH smoothing
> * Support for octree AMR codes
> * Preliminary Support for non-Cartesian data, such as cylindrical,
> spherical, and geographical
> * Revamped analysis framework for halos and halo catalogs, including
> direct ingestion and analysis of halo catalogs of several different
> formats
> * Support for multi-fluid datasets and datasets containing multiple
> particle types
> * Flexible support for dynamically defining new particle types using
> filters on existing particle types or by combining different particle
> types.
> * Vastly improved support for loading generic grid, AMR, hexahedral
> mesh, and particle without hand-coding a frontend for a particular
> data format.
> * New frontends for ART, ARTIO, Boxlib, Chombo, FITS, GDF, Subfind,
> Rockstar, Pluto, RAMSES, SDF, Gadget, OWLS, PyNE, Tipsy, as well as
> rewritten frontends for Enzo, FLASH, Athena, and generic data.
> * First release to support installation of yt on Windows
> * Extended capabilities for construction of simulated observations,
> and new facilities for analyzing and visualizing FITS images and cube
> data
> * Many performance improvements
>
> This release is the first of several; while most functionality from
> the previous generation of yt has been updated to work with yt 3.0, it
> does not yet have feature parity in all respects. While the core of
> yt is stable, we suggest the support for analysis modules and volume
> rendering be viewed as a late-stage beta, with a series of additional
> releases (3.1, 3.2, etc) appearing over the course of the next year to
> improve support in these areas.
>
> For more information, including 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.0 at http://yt-project.org/docs/3.0
>
> yt is the product of a large community of developers and users and we
> are extraordinarily grateful for and proud of their contributions. yt
> 3.0 features contributions from over 60 individuals, constituting
> almost 5000 commits. For many contributors, this is the first release
> featuring their work.
>
> Please forward this announcement on to any interested parties, and
> look for information soon about upcoming workshops focused on yt and
> applying it to your data.
>
> Thank you,
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "PyNE" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pyne-dev+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
The yt community is proud to announce the release of yt 3.0.
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 simulations and
nuclear engineering simulations.
This release of yt features an entirely rewritten infrastructure for
data ingestion, indexing, and representation. While past versions of
yt were focused on analysis and visualization of data structured as
regular grids, this release features full support for particle
(discrete point) data such as N-body and SPH data, irregular
hexahedral mesh data, and data organized via octrees. This
infrastructure will be extended in future versions for high-fidelity
representation of unstructured mesh datasets.
Highlighted changes in yt 3.0:
* Units now permeate the code base, enabling self-consistent unit
transformations of all arrays and quantities returned by yt.
* Particle data is now supported using a lightweight octree. SPH
data can be smoothed onto an adaptively-defined mesh using standard
SPH smoothing
* Support for octree AMR codes
* Preliminary Support for non-Cartesian data, such as cylindrical,
spherical, and geographical
* Revamped analysis framework for halos and halo catalogs, including
direct ingestion and analysis of halo catalogs of several different
formats
* Support for multi-fluid datasets and datasets containing multiple
particle types
* Flexible support for dynamically defining new particle types using
filters on existing particle types or by combining different particle
types.
* Vastly improved support for loading generic grid, AMR, hexahedral
mesh, and particle without hand-coding a frontend for a particular
data format.
* New frontends for ART, ARTIO, Boxlib, Chombo, FITS, GDF, Subfind,
Rockstar, Pluto, RAMSES, SDF, Gadget, OWLS, PyNE, Tipsy, as well as
rewritten frontends for Enzo, FLASH, Athena, and generic data.
* First release to support installation of yt on Windows
* Extended capabilities for construction of simulated observations,
and new facilities for analyzing and visualizing FITS images and cube
data
* Many performance improvements
This release is the first of several; while most functionality from
the previous generation of yt has been updated to work with yt 3.0, it
does not yet have feature parity in all respects. While the core of
yt is stable, we suggest the support for analysis modules and volume
rendering be viewed as a late-stage beta, with a series of additional
releases (3.1, 3.2, etc) appearing over the course of the next year to
improve support in these areas.
For more information, including 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.0 at http://yt-project.org/docs/3.0
yt is the product of a large community of developers and users and we
are extraordinarily grateful for and proud of their contributions. yt
3.0 features contributions from over 60 individuals, constituting
almost 5000 commits. For many contributors, this is the first release
featuring their work.
Please forward this announcement on to any interested parties, and
look for information soon about upcoming workshops focused on yt and
applying it to your data.
Thank you,
Hi all,
I've run into an issue where rockstar catalogs that were generated before
the SDF PR was merged no longer load correctly in the current tip of yt. I
believe we actually saw this the other day when the rockstar dataset on
yt-project.org/data was being used to show an example of annotate_halos in
the docs and was producing obviously incorrect results. The problem went
away after a new catalog was generated with the same script.
If anyone has any insight into what might have changed in the rockstar
output and frontend to make them incompatible with those that existed
before the SDF PR, please let me know. If it helps, here is a simple
script that can be run on the enzo_tiny_cosmology data.
http://paste.yt-project.org/show/4986/
Thanks,
Britton
I've been playing around with the orientation of the VR images and have a
PR that introduces a fix, but as thinking about 3d and understanding it
when looking at 2d projections is, at times, confusing, I put together some
examples and would like comment.
The test dataset is a simple one. The domain is [-1,1]^3, and there is a
single cube on the +x axis, two cubes on +y, and three on +z. There is a
sphere at the center, and the planes corresponding to x = xmin, y = ymin,
and z = zmin are highlighted as well.
First point of confusion is what is the direction of the normal vector we
use in the camera setup. The docstring says "The vector between the camera
position and the center". For all of the renderings, I put the center of
the camera at (0,0,0), so the docs suggest that the vector should point
from where I am standing toward the origin. Therefore, if I want my view
to hover in the +x, +y, +z quadrant, I would set it to (-1, -1, -1). But I
seem to find that the normal vector points outward from the center, and
(1,1,1) gives me what I want.
To make sense of all of these, here are three different views, with the old
(current in yt) orientation and the one in my PR 1117. For each I also
show an animation where I rotate in yaw (I thought I was doing 360 degrees,
but it is not quite a full circle, but I'm not worrying about that now).
http://bender.astro.sunysb.edu/yt-experiments/
you may need to stare at these a bit to get a sense of the rotation, but it
should be right-handed, so that should help break any degeneracies.
Note that I don't use draw_domain() because it does not work (yet) with the
fix in the PR (because the image is upside down when it is drawn).
If you know the VR well, please comment as to whether I am just still
confused, or if the PR seems to get things right. It matches my
expectations, but I may be making some wrong assumptions about what we want
the VR to do.
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
New issue 875: accessing field ('all', 'particle_phi_spherical') fails with units error
https://bitbucket.org/yt_analysis/yt/issue/875/accessing-field-all-partic...
Cameron Hummels:
As I'm doing some last minute testing with yt, i tried to look at the units output by different fields. so i loaded up some of the sample datasets and ran:
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
ad['io', 'particle_phi_spherical'] # or ad['all', 'particle_phi_spherical']
It fails with this error:
http://paste.yt-project.org/show/E61GH2U1zxq4yYo2l8qD
