I was just chatting with Nathan about the MAESTRO frontend in yt, and it appears it is causing some confusion with other BoxLib-based data formats during loading. In particular, the MAESTRO frontend looks for a "job_info" file to identify itself as a MAESTRO data set. However, the CASTRO code (which should be released soon…) --- and hence Nyx --- have since been updated to also dump job_info files into their data sets, thus causing the confusion.
For the time being, I would recommend turning off the MAESTRO frontend in yt. I think I was the only one to have ever used it --- MAESTRO isn't currently publicly available. I have been wanting to put in more work with the yt project, and have had fixing/cleaning up the MAESTRO frontend on my TODO list for quite some time, but it is my someday/maybe pile. Hopefully I'll have some time soon to make this more of a priority!
Chris Malone (malone(a)ucolick.org)
Dept. of Astronomy and Astrophysics
UC Santa Cruz
1156 High Street
Santa Cruz, CA 95064-1077
Sam and I are working on issuing a PR about the volume rendering
refactor. This is the last major code change to go in place for 2.4,
pending the quad_proj changes being accepted or rejected. I'm still
thinking about this refine_by issue, and that might also make it in.
After the volume_refactor, it's just testing and documentation left:
After 2.4 is released, I am going to shift my new development
exclusively to the yt-3.0 branch, which is currently hosted here:
This will include geometry refactoring and many remaining
de-Enzoifications of the code base. 3.0 is nearing a usable state,
but will not be ready for production for a while. However, I think
that allowing the codebases to diverge too rapidly will lead to
problems: a fracturing. So once the 3.0 codebase can muster feature
parity with 2.x, I am going to ask that all development on the 2.x
branch cease, and all pull requests for features and new functionality
be applied only to the 3.0 branch. In advance of this, I would like
to solicit help: we've identified a number of relatively
straightforward changes to this code base that can and should be made.
For instance, the changing of field names. I'd also like to consider
moving to a more spread-out source code layout, like one class per
file. Changes like these make it difficult to do cross-branch merges
and transplants, which is why I would like to save them for after
feature parity has been reached and development on 2.x has halted.
If anyone has any strong objections to this strategy, please reply.
* June 26, 2.4 release
* July 30, 3.0 reaches rough feature parity
* Fall sometime: 3.0 merged into main 'yt' branch
* Some time after that: 3.0 released
Criteria for Feature Parity:
* All patch-based AMR codes support data region selection
* Parallelism is functional for all parallel-capable routines
* All patch-based AMR codes support projections, slices, cutting planes
* All patch-based AMR codes support volume rendering
* All patch-based AMR codes support halo finding
* Octree-based AMR codes (RAMSES and ART) support data region selection
* Octree-based AMR codes (RAMSES and ART) support slices, projections
and cutting planes
If any of you are interested in helping with this reengineering
effort, I would be extremely interested in collaborating. My goal for
this effort is to focus on making yt a future-compatible code, and
changing it from an organically grown system into one that we design
based on the years of experience we all have now had with it.
I just recently got a brand-spankin' new mac laptop and I'm trying to
see if I can get yt installed. I'm upgraded to Mountain Lion, so I
realize I might be in unexplored territory, but I thought maybe I
could get the tips and trick for getting things installed on Lion and
perhaps they will translate well. As it stands currently, the install
script is failing when it tries to install matplotlib and it seems to
be an issue with freetype (or perhaps the compiler). This is the
output of yt_install.log after pip successfully installs:
Any help/suggestions would be greatly appreciated.
"I'm here to fight for truth, and justice, and the American way."
Hi all on yt-dev,
I wanted to write to say thank you all for your help with this
release. The vital stats:
* Between yt 2.3 and yt 2.4, there were about eight months of calendar time
* We had the first workshop at UChicago during that time
* This release had 1200 changesets contribute to it, for a total of
* 21 people contributed changes, 6 of which were first-time contributors
* We closed 42 issues targeted at 2.4
* This was our first PR-based development cycle, and we went through
nearly 200 of them
Thanks also to Nathan and Sam, who burned the midnight oil last night
to get the docs built (with new added VR) and send out the release
announcement. And Nathan, who really grabbed ahold of the PlotWindow
and pushed on making it look nice, making it work nice, and making it
a desirable alternative to the PlotCollection, was one of those first
time contributors! So congratulations everyone, and again, thank you
all for your hard work.
On Thu, Aug 2, 2012 at 11:18 PM, Nathan Goldbaum <nathan12343(a)gmail.com> wrote:
> Dear Colleagues,
> We’re proud to announce the release of version 2.4 of the yt Project,
> http://yt-project.org/ . The new version includes many new features,
> refinements of existing features and numerous bugfixes. We encourage
> all users to upgrade to take advantage of the changes.
> yt is a community-developed analysis and visualization toolkit,
> primarily directed at astrophysical hydrodynamics simulations. It
> provides full support for output from the Enzo, FLASH, Orion, and Nyx
> codes, with preliminary support for several others. It provides
> access to simulation data using an intuitive python interface, can
> perform many common visualization tasks and offers a framework for
> conducting data reductions and analysis of simulation data.
> The most visible changes with the 2.4 release include:
> * A threaded volume renderer, which has been completely rewritten for
> speed, clarity and extensibility
> * A new plotting mechanism, the “Plot Window,” for easier and more
> efficient visualization
> * Many improvements to time series analysis, including auto-parallelization
> * A complete rewrite of the Web GUI for yt including a WebGL 3D scene
> and substantial user interface improvements
> * Integration with the new yt Hub (http://hub.yt-project.org/ ) for
> sharing of data, scripts and images
> * Extensive additions and improvements to the cookbook
> For a complete list of changes in this release, please visit the
> Changelog ( http://yt-project.org/docs/2.4/changelog.html ).
> Information about the yt project, including installation instructions,
> can be found on the homepage: http://yt-project.org/
> Development of yt has been sponsored by the NSF, the DOE, and various
> universities. We develop yt in the open and encourage contributions
> from users who extend and improve the code. We invite you to get
> involved with developing and using yt!
> Please forward this announcement to other interested parties.
> The yt development team
> You received this message because you are subscribed to the Google Groups "enzo-dev" group.
> To post to this group, send email to enzo-dev(a)googlegroups.com.
> To unsubscribe from this group, send email to enzo-dev+unsubscribe(a)googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/enzo-dev?hl=en.
I'm not sure if this is related to the latest changes in volume rendering,
I just updated my YT to see if the strange behavior of transfer function
was fixed, but my old script which rotates the cube using cam.rotation now
rotates the cube in strange ways, like the north vector is being redefined
half way through the rotation.
Here's the script I used, and I just updated to the latest YT
(dev-yt)4-c-ce-e0-97-1e:yt-hg gso$ hg summary
parent: 6186:2ff4b9960158 tip
This is the last call for 2.4 *code* changes. Any changes which don't
fix the Transfer Function bug should be held off on, or put into a
pull request so that they can be evaluated as bug fixes.
1. Docs for VR & the hub
2. Transfer function bug (
). Sam has a script at http://paste.yt-project.org/show/2609/
3. Merge to stable
4. Release announcement / tarball / etc
1 is independent, 3 is blocked on 2, and between 3 and 4 we can wait a
bit after unfreezing the development branch.
This PR is something Sam and I went over in IRC the other day.
Basically, the current method that supports opaque rendering doesn't
always give the same results one usually wants for "onion peel" volume
rendering. This PR restores that functionality but provides a
conditional for when you want to insert opaque surfaces. I think this
should go in for 2.4. Sam, at your leisure could you take a look at
PS I came upon this while creating an example IPython notebook for
2.4. I'm going to mail it out later and ask for feedback, but I think
it's a pretty neat way of showing features!
---------- Forwarded message ----------
From: Matthew Turk <pullrequests-noreply(a)bitbucket.org>
Date: Wed, Aug 1, 2012 at 10:47 AM
Subject: [yt_analysis/yt] Grey opacity for volume rendering (pull request #231)
A new pull request has been opened by Matthew Turk.
MatthewTurk/yt has changes to be pulled into yt_analysis/yt.
Title: Grey opacity for volume rendering
Adding a grey_opacity option to the ColorTransferFunction object.
Here's an example script demonstrating it:
When set the False (the default) images look very similar to the
old-style VR, before the refactor:
When set to True, the inner layers get attenuated:
This is set to non-grey by default, to preserve old behavior.
Changes to be pulled:
This is an issue notification from bitbucket.org.
You are receiving this either because you are the participating
in a pull request, or you are following it.