I've been thinking about the best way to construct minimal image
representations, which feed into the Reason / plotting refactor ideas.
I started sketching out a minimally-reproducible phase plot in
yt/visualization/profile_plotter.py, in the objects
I think that as it stands it encompasses how to save and then recreate
a (simply) visualization, but I was wondering if some other people
could look that over, and help me come up with ideas for what would be
necessary to also make sure it faithfully represents image plots, 1D
line plots, and so on. IT doesn't need to cover all possibilities,
just the basic ones.
Anyway, ideas would be greatly appreciated! Thanks!
I just put linear tickers into the Reason plot widget, copying from
matplotlib like Matt did for the log tickers. However, it doesn't seem
to want to print negative tick labels. The negative sign is there, but
no number. I think this might be on the js side, and a cursory glance
didn't reveal anything. Any ideas?
I wonder if any of you saw this:
It's about baryonic inflows and outflows from galaxies, and discusses
both observations and simulations. There are a few images shown made
from their simulations that use streamlines to show the path of gas in
and out of galaxies. The neat thing is I think that yt isn't too far
from being able to do this, we just have to make the streamlines work
over time-ordered datasets. I just thought you all might find it
interesting, and hopefully all of your various .edu institutions have
a subscription so you can see the full article online.
510.621.3687 (google voice)
I'm having trouble writing a plot png to disk, and it seems that my dev
installation script might be the culprit, it's giving me the error:
line 180, in get_text_width_height_descent
font = self._get_agg_font(prop)
line 221, in _get_agg_font
font = FT2Font(str(fname))
RuntimeError: Could not open facefile
In the installation script on line 578 there's:
if [ -e $HOME/.matplotlib/fontList.cache ] && \
( grep -q python2.6 $HOME/.matplotlib/fontList.cache )
looking for the 2.6 stuff, even though it installed 2.7, could this be the
cause of my problem? Will changing the 2.6 to 2.7 fix it?
I added some debugging statements to Reason that get turned on with
the -d flag. These will output whenever a payload is added, whenever
a heartbeat is felt, whenever payloads are delivered, and with the
input/output of cell contents and executed code. This should do it:
yt serve -d
(There are also the -f and -o options.)
Also, I discovered that I added a Python 2.7-only feature without
thinking, so Reason currently won't work with < 2.7.
This gets used in extdirect_repl.py on line 162 -- if somebody has a
better idea how to handle this, it'd be great if we could simply
replace it. Otherwise, we'll just mandate 2.7.
As it stands there are a couple big fish that need to be landed before
this can be public: debugging and lots of use (although I am now using
it all the time, almost exclusively, for analyzing my data), volume
rendering widget (maybe something that looks like a less busy version
of the widget I made with Traits in 2009?
http://www.flickr.com/photos/matthewturk/4189749374/ ), phase plot /
histogram of currently visible rectangular prism in the plot window
widget, colorbar for plot window, and a few other things that are
slipping my mind.
Anyway, because it's still in flux and a bit finicky in places, it's
probably better not to publicize it too much. Once it's working
better we can have a go at asking for beta testers and whatnot.
This morning and yesterday I spent some time trying to diagnose an
issue with the halo profiles when using a recentering function. In
summary, with a recentering fuction, a large majority of the profiles
generated would have zero- and nan-valued inner-most bins for all the
fields except for radius. I believe Britton saw this as well. I think
I have tracked down the proximate cause, but I don't know quite what
it means or the best solution. Sorry to those of you who I am going to
patronize with some descriptions below.
In data_objects/profiles.py, in the function _get_bins() (all of this
is for 1D profiles), the radius of each cell is found in relation to
the center of the sphere, and then a dict of arrays of which cells
belong in which radial bin is built. This dict is then used to pull
out values from fields to make the profiles. I'm finding that with
recentering, for the profiles with zeroed first bins, there are no
cells being put into the inner-most bin. Furthermore, I'm finding that
in all* these cases there are exactly 6 cells that are within 1e-10 of
the inner-most bin edge, and are being excluded from binning. If these
cells were included, the inner-most bin would not be empty.
It seems to me that this problem may be a numerical and geometric one,
but I can't quite convince myself of this. What do all of you think?
In a somewhat related question, the parameter "end_collect" controls
whether or not bins that fall outside of the min/max of the profile
range are included in the binning. The halo profiler currently uses
the default, which turns "end_collect" off, so cells outside the
min/max are thrown away. It seems to me that we may want to make
including all cells inside the minimum radius default as part of the
inner-most bin. This would instantly solve the problem above, but I
don't know if this is correct. It may even match how observers do
things with their finite beam widths.
Thanks for your comments!
(* "all" means I have yet to find a counter-example. The universe is
very large, however.)
510.621.3687 (google voice)
There is a fair amount of discussion about the HaloProfiler being a
replacement for enzo_anyl. I would definitely like to see this become
official, since it seems to be keeping a number of people from making the
switch to YT. Can somebody outline the things that enzo_anyl does that the
HaloProfiler cannot? I have been under the impression that there wasn't
anything, but I haven't used enzo_anyl in quite a while.
Just wanted to update those of you who weren't following along in
http://yt.enzotools.org/irc.html (which i will note led to a very fast
development pace today), we've added a grid viewer widget to reason. This
is a way of viewing the grid edges of your simulation, and is implemented in
WebGL. You will need to grab the latest install script because this
requires a package called PhiloGL. Download the new script and run it and
you should be set to go. You will also have to have a browser that supports
WebGL, but if you have something like the latest chrome or firefox, you
_should_ be fine...no promises.
There are certainly bugs to be worked out (i.e. if you are using a sim with
a lot of grids they might not all show up), but you should be able to
navigate with your mouse:
Planned possible additions:
Coloring grids by level
"look at" button to either enter a coordinate by hand or by max density,
right click to focus (like an interactive "look at")
Move through using arrows
If you have any feedback, we'd love to hear it!
The plan is to finish up our initial work on the new YT gui: Reason
on Monday in a sprint. There are still a handful of outstanding issues
that we should clean up before launching it to the community:
-- File input dialog box
-- Hotkeys for plot windows
-- Relabeling plot windows to be more unique to the particular session
(DD0125 Temperature Slice, etc.)
-- Metadata displayed in plot windows
-- Colorbar displayed in plot windows
-- X, Y bounds shown on plot windows
-- Center on click on plot windows
-- Center on max button in plot window dialogs
There may be a few more but that is all I can think of right now. After
we clear these issues out, I think reason will be ready for an official
launch along with the next subversion of yt: 2.2.
So if you're interested in participating, let's meet on Monday at 11:00
AM EDT on the #yt irc channel. Bring the Kraftwerk!
I am thinking of making a modification to how the halo profiler works,
which I think will be an improvement. I wanted to pass this idea by
you all (especially Britton) just to make surre I'm not stepping on
any toes or there's some problem with this I haven't thought of.
Currently, if you want to adjust the center of a halo for the purposes
of making the profile, such as to the point of maximum gas density in
the sphere defined by the halo, you'd call the HaloProfiler with
``use_density_center=True``. But if instead you want to use some other
fields maximum point, you specify it using the
``use_field_max_center`` keyword. There is no functionality for
specifying that the center should be moved to the minimum of some
quantity, like the temperature for a cool-core cluster. I could easily
add a parameter like that ``use_field_min_center``, but I think that
this is quickly becoming unwieldy and inelegant.
I propose that these two extant parameters, and any future ones like
the example above, be replaced by a simple function that can be passed
to the HaloProfiler object. For example, if you'd want to recenter on
the maximum density point, it might look something like this:
ma, maxi, mx, my, mz, mg = sphere.quantities['MaxLocation']('Density')
hp = HP.halo_profiler("DD0242/DD0242", recenter=_recenter_on_dens)
The function can do whatever the user wants, unlike the limitations of
the specific parameters currently in the HaloProfiler. I'd of course
add some useful examples to the documentation. Let me know what you
510.621.3687 (google voice)