Mailman 3 March 2010 - yt-dev

yt structure
by Stephen Skory 07 Mar '10

07 Mar '10

Howdy y'all, I'm wondering if there is a system to deciding when something belongs in yt.lagos (like the HaloFinders), or in yt.extensions (like the HaloProfiler)? For example, I'm thinking of adding a simple bit of code that will calculate the star formation history (Msol/year, for example) for a given set of stars. Would that go in extensions or in lagos? The best I can tell is that extensions are more secondary, as in they are a post-processor of already refined data, while lagos handles the raw data and refines it down. Thanks! _______________________________________________________ sskory(a)physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

3 5

hg subrepos
by Matthew Turk 06 Mar '10

06 Mar '10

Hi guys, Mercurial 1.5 was released yesterday, and it includes support for "subrepos" -- like what is done in the Enzo-1.5 SVN repository. http://mercurial.selenic.com/wiki/subrepos This means that other hg repos can be included in a single, unified repository. Very cool, and we might be able to use this for things like the cookbook, the barn, the yt repo, and any other sub-projects of yt. hg includes svn support as well in the subrepos. :) -Matt

1 0

mercurial stability
by Matthew Turk 05 Mar '10

05 Mar '10

Hi all, I just wanted to drop you all a note -- I've consolidated a bunch of branches, and also made some changes to the volume renderer, and stuck all that in the main 'yt' branch in hg. This includes: 1. Volume Renderer calculates which grids are necessary via the InclinedBox; this means the grids that get partitioned are dependent on orientiation. 2. (nascent) Chombo support has been merged in. 3. (nascent, inefficient) Gadget support has been merged in. We may be adding at least one more code over the next two months, possibly two codes, so I am also planning to do some reorganization of the file system in the mercurial repo -- probably in a different branch -- to separate things by code and to codify units and parameters a bit more. I'll keep you all up to date. Right now Chombo is unsupported, but it sort-of-works, modulo unit problems. (Three cheers for Jeff, who wrote the whole thing in like an hour!) -Matt

1 0

EPD
by Stephen Skory 03 Mar '10

03 Mar '10

Hi All, apparently the 6.1 release links against the Intel Math Kernel Library and Numpy/Scipy routines run quite a bit faster. A good reason to think about using EPD. http://tinyurl.com/yzadmdg _______________________________________________________ sskory(a)physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

1 0

Proposed change of default colormap
by Matthew Turk 01 Mar '10

01 Mar '10

Hi all, I'd like to propose we change from "jet" as our default colormap to "bds_highcontrast". I've attached sample images of the same simulation -- I think bds_highcontrast (designed by our very own Britton, nearly two years ago now) is better looking and is easier to discern differences in. I've provided a patch that should make this change here: http://paste.enzotools.org/show/344/ It applies to trunk. If this goes through, we'll also make our plots slightly better distinguished, too, because this is a homegrown colormap. (We also have the "kamae" colormap, created by Tune Kamae, that isn't in matplotlib and that I think is criminally underused overall.) Also, maybe it should be aliased as something in addition to "bds_highcontrast"? Another name? -Matt

3 4