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
________________________________(_)_\(_)_______________
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
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
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
________________________________(_)_\(_)_______________
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
