Mailman 3 August 2012 - yt-dev

MAESTRO frontend
by Chris Malone 07 Aug '12

07 Aug '12

Hi dev-team, 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 ------------------------------------------------------------------------- Chris Malone (malone(a)ucolick.org) Dept. of Astronomy and Astrophysics UC Santa Cruz 1156 High Street Santa Cruz, CA 95064-1077 phone: 831-459-3809 -------------------------------------------------------------------------

2 1

Near- and mid-term roadmap: 2.4, 2.x, 3.0
by Matthew Turk 07 Aug '12

07 Aug '12

Hi all, 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: https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&mileston… 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: http://bitbucket.org/yt_analysis/yt-3.0 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. Previous threads: http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001… http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001… http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001… http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001941… http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001949… If anyone has any strong objections to this strategy, please reply. Estimated Timeline: * 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. -Matt

4 6

Installing yt on Mountain Lion?
by Devin Silvia 06 Aug '12

06 Aug '12

Howdy yt-dev, 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: http://paste.yt-project.org/show/2622/ Any help/suggestions would be greatly appreciated. Thanks, Devin -- "I'm here to fight for truth, and justice, and the American way."

4 4

Re: [yt-dev] [enzo-dev] yt 2.4 release announcement
by Matthew Turk 03 Aug '12

03 Aug '12

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. Best, Matt 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. > > Sincerely, > > 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. >

2 1

cam.rotation changes north vector?
by Geoffrey So 01 Aug '12

01 Aug '12

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 http://paste.yt-project.org/show/2612/ (dev-yt)4-c-ce-e0-97-1e:yt-hg gso$ hg summary parent: 6186:2ff4b9960158 tip From G.S.

3 4

Last call for 2.4
by Matthew Turk 01 Aug '12

01 Aug '12

Hi all, 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. Remaining: 1. Docs for VR & the hub 2. Transfer function bug ( https://bitbucket.org/yt_analysis/yt/issue/390/transfer-function-bounds ). 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. -Matt

1 0

Fwd: [yt_analysis/yt] Grey opacity for volume rendering (pull request #231)
by Matthew Turk 01 Aug '12

01 Aug '12

Hi all, 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 this? -Matt 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) To: yt(a)enzotools.org A new pull request has been opened by Matthew Turk. MatthewTurk/yt has changes to be pulled into yt_analysis/yt. https://bitbucket.org/yt_analysis/yt/pull-request/231/grey-opacity-for-volu… Title: Grey opacity for volume rendering Adding a grey_opacity option to the ColorTransferFunction object. Here's an example script demonstrating it: http://paste.yt-project.org/show/2605/ When set the False (the default) images look very similar to the old-style VR, before the refactor: http://i.imgur.com/CXkIE.png When set to True, the inner layers get attenuated: http://i.imgur.com/TRy2q.png 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.

1 0