Mailman 3 April 2009 - yt-dev

reproducible HOP halo IDs
by Stephen Skory 20 Apr '09

20 Apr '09

Hi all, I propose to add these lines to SS_HopOutput which will ensure that runs of (parallel) HOP will output haloes with the same ID every time, regardless of threads, for the same threshold. http://paste.enzotools.org/show/103/ If there are no complaints, I'll commit it. _______________________________________________________ sskory(a)physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

2 1

"halo cutter" ticket
by Matthew Turk 18 Apr '09

18 Apr '09

Hi guys, Does anyone remember what this ticket is about? I think it was spurned by some discussion I had with Stephen, possibly in this venue. Was this about doing thin-slice projections and wanting the Hop callback to only display halos in the thin slices? http://yt.enzotools.org/ticket/194 -Matt

2 2

Needs review: data labels
by Matthew Turk 17 Apr '09

17 Apr '09

Hi guys, I need someone (Jeff? This is sort of in your wheelhouse) to look at this patch: http://paste.enzotools.org/show/99/ It's designed to change the way display labels are calculated for plots, specifically slice and projection plots. I'd like to commit it and close #130, as it adds a display_name option to fields which overrides the field name. After review, I'll commit. -Matt

2 1

DM-only runs
by Matthew Turk 16 Apr '09

16 Apr '09

Hi guys, Anybody have any small DM-only runs they don't mind sharing? My access to fresh enzo data is a bit finicky for the next few days, but I want to tackle ticket #207. -Matt

2 2

Re: [Yt-dev] Updating MPlot3D to a more recent matplotlib.
by Matt 15 Apr '09

15 Apr '09

FYI, but does not include volume rendering. I'll bump the downloaded MPL upon the next release and then convert the s2plot hop plotting to MPL. Sent to you by Matt via Google Reader: Re: Updating MPlot3D to a more recent matplotlib. via gmane.comp.python.matplotlib.devel by John Hunter on 4/14/09 Worked beautifully -- *may thanks* for your continued work on this port. Many folks were disappointed to see this functionality yanked away, and it is nice to have it back. I committed it as mpl_toolkits/mplot3d and added examples/mplot3d/demo.py. This latter file actually does all of the demos that are in axes3d, so it is a bit richer than the original demo. Send me your sf id and I will add you to the committers list so you can continue to update the software. Thanks! JDH ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com Things you can do from here: - Subscribe to gmane.comp.python.matplotlib.devel using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites

1 0

disk analysis
by Matthew Turk 13 Apr '09

13 Apr '09

Hi guys, After some chats with Jeff this morning, and following up on those with a discussion with Ji-hoon Kim, I'd like to bring up the idea of disk analysis. I will summarize first the current status and then where I think it can be taken over the next week or so. Currently, disks can be analyzed by calculating the angular momentum vector over some known sphere, then using that to bin quantities by height/radius. Cutting planes (thin) can be made with the code, AMRCylinders (without any *new* or *tranformed* spatial information) can be constructed and binned. Projected cutting planes can be made, but it is kind of slow and a recipe has to be used rather than a simple, provided API. Inertial tensor fields are available, but have to be manually diagonalized. In short, there's a lot that can be done, but it's not terribly easy. I'd like to see this expand to be handled through a single interface, similar to the halo profiler, called the DiskAnalyzer. This would take a sphere, or some region, step out over spherical shells and at each shell identify the declination from an abitrary vector (possibly bulk L_vec of the data source as a whole) of the average density. It would calculate the scale height for the density in that spherical shell. Once this is done, the scale height as a function of radius will be had, as well as the alignment of the disk as a function of declination from the central (arbitrary) vector. Once this information is collected, we need to construct a disk 'image.' As I see it, this can be aligned with the angle of maximum density, as calculated by binning by declination from our arbitrary vector. However, one could also imagine aligning it with the angular momentum vector (commonly done now) or the diagonalized inertial tensor. I'm not sure which is the right one to do. At this point, profiles as a function of scale height and radius are possible or already completed, and we have a disk image. Toomre Q can be calculated and we should have complete set of diagnostics for the disk. Can anyone think of what else should be done? And are there any flaws in my proposal? (What about the vector for defining the projected image -- which is the best of the three?) Thanks guys! -Matt PS I'm getting half of my wisdom removed on Tuesday, so I will be on painkillers a bit this week, so I will be in and out of email contact.

1 0

Fwd: AMR in MayaVi
by Matthew Turk 08 Apr '09

08 Apr '09

FYI ---------- Forwarded message ---------- From: Prabhu Ramachandran <prabhu(a)aero.iitb.ac.in> Date: Wed, Apr 8, 2009 at 10:31 AM Subject: Re: AMR in MayaVi To: Matthew Turk <matthewturk(a)gmail.com> Hey Matt, I've been a little busy, hence the slow response. On 04/05/09 11:26, Matthew Turk wrote: > > A while back we chatted about including AMR in MayaVi2. I was > wondering what the current status was of using the > HierarchicalBoxDataSet as a data source -- the patch to allow direct > addressing of this, that made it into VTK CVS, is going to be included > in the EPD (ticket #600: https://svn.enthought.com/epd/ticket/600 ) > and we're eager to start integrating more fully with MayaVi. I > believe the major differences would be constructing > HierarchicalBoxDataSets and changing the executive to > CompositeDataPipeline. IIRC there is also a little extra work needed to get the data ranges and stuff so it works nicely with mayavi and its module manager etc. > We have started converting to a Traits-based GUI for our analysis > package ( http://yt.enzotools.org/attachment/wiki/Screenshots/reason_v2.png > ) and have started using TVTK scene objects as our editors, etc, but > using MayaVi properly would be far better -- we're currently > constructing all of our own objects, rather than pipelines, based on > VTK primitives. Using the pre-built MayaVi pipelines would be pretty > excellent -- and certainly much easier! The interfaces for both > MayaVi and mlab are very impressive, as you know. Thanks for the compliments, the screenshot is really cool. > Also, a couple months ago you mentioned you had a student looking into > parallel rendering with mayavi & tvtk. Did he ever end up having > success? The student did get a fully working patch against the then mayavi svn trunk but there were a few issues I wanted addressed and I gave the problem over to another student who has been busy with other work and has also not picked up enough to take it ahead. I am hoping this will be resolved by this month end though. I've been pestering the student to get this done ASAP. Right now he is working on a couple of features and will start this work next week I hope. cheers, prabhu

1 0

Output logging
by Matthew Turk 04 Apr '09

04 Apr '09

Hi guys, Can anybody give me a flavor of the widespread usage of the file "OutputLog" with Enzo? I can't recall when this was added -- just prior to 1.5? -Matt

2 2

Re: [Yt-dev] OpenGL backend and pyglet expertiments
by Matt 03 Apr '09

03 Apr '09

Just as a note, looks like IPython will have a pyglet array interface. Because of how yt.raven._MPL pixelizes, this could be used as a means of interactive zooming and panning using OpenGL to render instead of Agg. _MPL.Pixelize might have to have a buffer argument added, which could then be the buffer plotted, but otherwise it would be rather straightforward. Sent to you by Matt via Google Reader: Re: OpenGL backend and pyglet expertiments via gmane.comp.python.matplotlib.devel by Fernando Perez on 4/3/09 On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier public.gmane.org> wrote: Great! Would you have any interest in having this be shipped/developed as part of IPython itself? You are using a fair amount of internals of the ipython machinery, and we're getting ready for a large cleanup. Having your code shipped with ipython itself would give it perhaps more exposure, as well as allow it to evolve in sync with the rest of the API, since we could test it as the internals change. I think it would be great to ship this with ipython itself, and I'm sure you'd get help and contributions from the rest of the ipython team as well... Best, f ------------------------------------------------------------------------------ Things you can do from here: - Subscribe to gmane.comp.python.matplotlib.devel using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites

1 0

gas energy, total energy and field aliases
by Matthew Turk 03 Apr '09

03 Apr '09

Hi guys, I don't know if you guys have noticed, but there are lots of different field names for Gas Energy and Total Energy, depending on both branch of the code and test problem. (LCA 1.5 even still has an underscore in the rotating cylinder problem!) This bit me today and I thought about it, and I think the solution is -- in this two-choice case -- to have aliases. I've committed a change to bitbucket that I'm going to test out tonight more extensively, but in my initial tests it successfully swapped out Gas_Energy & GasEnergy and Total_Energy & TotalEnergy. Does anyone see any problems with it? http://bitbucket.org/MatthewTurk/yt/changeset/9f624c382c1a/ If not, I'll commit tomorrow or the day after. I believe ThermalEnergy is currently broken with LCA1.5, and this would fix it. -Matt

3 5