Hi,
What do we think is the best way to go about adding a very basic benchmarking tool to yt?
Right now my thought is to simply add to mylog 'benchmark'. For each part you wanted to benchmark you'd wrap it with two statements:
mylog.benchmark('start complicated mess')
...
mylog.benchmark('end complicated mess')
Instead of printing this to stderr/out, it would go to a standard file, or something that could be easily analyzed by a simple function. The nice thing about using mylog is Matt has already got processor labels working, and it has timestamps. It would be therefore also trivial to have nested benchmarked sections, etc...
Thanks for your comments!
_______________________________________________________
sskory(a)physics.ucsd.edu o__ Stephen Skory
http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student
________________________________(_)_&#92;(_)_______________

Hi everyone,
It's come time to start moving stuff into the trunk, as opposed to
just being in mercurial. This means the trunk will become a faster
moving target. Bug fixes need to be committed to both yt-1.5 and yt
if they are to be made.
The following things will be moved into trunk:
* Integer covering grids replacing standard covering grids; smoothed
integer covering grids are not ready, so they will default back to
floating point math.
* Fixed resolution projections
* Next-generation GUI including inline VTK support.
Additionally, I will be targeting the hierarchy optimization more
heavily as well as a generalization of the floating point type used
for baryon fields and positioning.
Documentation is proceeding apace, and I have constructed most of a
cookbook, which I will be properly presenting later this weekend.
-Matt

Hi Stephen (et al),
I'm interested in taking particle-only data and putting it into a
regular, multi-level grid structure that has yet to be created. I
think using a kD-tree, where we specify a maximum number of particles
in a given region, could be used to identify regions that should be
covered by grids. Do you think that your kD-tree code would be
suitable for this?
-Matt

Hi all,
Adam Ginsburg, a grad student here at CU who does not work with yt, was kind
enough to add some nice features to set_zlim in RavenPlot, which are the
plots held in the PlotCollection. These features add some flexibility to
adding ticks to the colorbars on images.
Since he's not a regular yt user, I've submitted a code review on his
behalf. Please, check it out and leave comments here, if you have any:
http://review.enzotools.org/r/15/
Normally, an email would be automatically sent, but there was a small
error. Matt is fixing that now.
Britton

Hi guys,
After [chatting with / getting chewed out by] Brian, it's become clear
to me that while we have barely passable narrative documentation, the
cookbook is sorely lacking.
I'd like to start a brainstorming over what would be good to go in a
cookbook. I will use a sample dataset as input into a number of
things and then, in the documentation, include both the images and the
scripts inline for people to view. Additionally, these will all be
accessible somehow by automated download -- but I haven't quite worked
the specifics of that out yet. I am thinking along the lines of:
$ yt cookbook slices
and then have that spit something out into stdout, which it'll grab
off the web. (I'm toying with different ways of doing this.)
Anyway, can we get some discussion of the right things to include in
such a cookbook? I'm thinking the following:
simple slices
simple projections
simple phase plot of a sphere
simple radial profile of a sphere
cutting plane
overplotting contours on a slice
overplotting grid lines on a slice
quiver plot
Most of these are maybe one or two lines, so please feel free to
suggest other "simple" things as well as much more complicated ones.
I'd really like some feedback on this, so I have a good idea on what
*should be included*, y'know? What else should be in there?
-Matt

Hi guys,
I've updated the VMPlot type, for slices and projections, to use a
different method of setting the data. This should enable MUCH more
ease-of-use with callbacks, for instance, and also some speed
increase.
If two of you could grab the diff, apply it and see if it works for
oyu in your standard tests, that'd be awesome. If it does, just click
on "Review" on this page and then "Ship It" and I'll commit it.
http://review.enzotools.org/r/14/diff/
Thanks!
-Matt
PS I am liking review board. Email notifications are going to be set up shortly