New issue 1066: Default origins for different geometries based on axis
For some geometries, like cylindrical, there are natural origins for the plots one would want to use. For instance, if we are looking at a plot along R and z of a cylindrical dataset (i.e., slice along theta), we probably want "native" to be the default origin. Right now, this is not implemented, and in principle it should be implemented in a way that is a bit more rigorous than the way centers, widths, etc are currently set up.
in order to ease up website deployment after each commit to
yt_analysis/website I've set up webhook that will do all the magic after
each merge / push.
If anyone is interested in details, the machinery consists of:
1) webhook for push that posts to http://hub.yt/webdeploy/
(configurable on bb)
2) simple webservice that executes ssh to dickenson using custom key
3) following entry to .ssh/authorized_keys (at dickenson)
where 'deploy' == hg pull / update / archive
Let me know if there are any problems with it.
With mercurial it's easy to get into a state where you have many heads,
each one corresponding to a different open pull request on bitbucket. Up
until now it's been sort of awful to use bitbucket with many heads, since
the branch dropdown menu in the pull request interface only showed
changeset hashes when a named branch has more the one heads.
Now, thanks to Sean Farley at bitbucket, the PR dropdown menu looks like
[image: Inline image 1]
If you don't use bookmarks, you might want to try it. When you're
developing a feature, you can do:
$ hg bookmark my-feature
# lots of commits, bookmark always points at the most recent commit
$ hg push -B my-feature https://bitbucket.org/my_account/yt
One nice feature of bookmarks is that you can push new remote heads with
"hg push -B" without force-pushing. And now they'll be much easier to find
when you go and make your pull request!
Even better, the "experimental" bookmark in the destination repository is
now clearly marked as such.
Thanks for your hard work Sean! I'm looking forward to more hg improvements
in the coming months :)
New issue 1065: documentation error in ortho_ray for projection=1
The documentation of ortho_ray says, in describing coords, that "If you are casting along y, this will be (x,z)." In fact (empirically), the coord for casting along y is (z, x).
Version = 3.1
Changeset = 4eb22c6d6fd9 stable
Does anyone have ideas on how we can encourage people to use the
appropriate version of the docs?
There are two issues that I see:
- New users may not understand that there are different doc versions, so
they may look at the wrong version for information
- Google indexing previous doc versions
New issue 1064: Cannot access projection_plot.plots[string].axes objects
In 3.2 we can no longer access and modify the plot axes. In 3.1 this could be done with the following code:
p = yt.ProjectionPlot(ds,2,string,center=[cent,height,0],width=(wide,height),origin="native",data_source=cut,method='integrate',weight_field='temperature')
ax = p.plots[string].axes
ax.yaxis.set_ticks([0.00, 0.15, 0.30])
In 3.2, I get the following error when running the above code:
AttributeError Traceback (most recent call last)
<ipython-input-76-6e901a613181> in <module>()
16 ax = p.plots[string].axes
---> 17 ax.yaxis.set_ticks([0.00, 0.15, 0.30])
AttributeError: 'NoneType' object has no attribute 'yaxis'
New issue 1061: Poor projection plot image quality in 3.2
I recently started using 3.2 instead of 3.1 and noticed that the quality of the projection plot images decreased in the newest stable release of yt. I believe it is due to a lower resolution when rendering the plot in 3.2.
Attached is a plot of the same temperature data, using both 3.1 and 3.2. You will notice that in the 3.2 plot the shocks (green/blue temperature discontinuities) and the flame front (transition from red flame to yellow/green/blue gas) appear rough and pixelated, whereas they are nice and smooth in the 3.1 plot. This is not due to the computational cell size, as the cells along the flame and shocks are much smaller (3.333E-4 cm x 3.333E-4 cm) than the blocks you see in the plot image.
Below is the code I used to generate these plots. The data I used is here: [http://use.yt/upload/a2346bb9](http://use.yt/upload/a2346bb9)
The plot looks ok when using the default image size of 8, but when a larger image is used (I usually use 12) the quality is not as good.
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.colors as mcolors
from matplotlib.ticker import IndexLocator
colors1 = plt.cm.jet(np.linspace(0.0, 0.9, 1*2200)) #(0.2, 0.8, 25))
colors2 = plt.cm.hot_r(np.linspace(0.95, 1., 1*7716)) # 7716
colors3 = plt.cm.hot(np.linspace(0., 0.8, 1*14660)) # 14660 start at 2600K
colors = np.vstack((colors1, colors2, colors3))
mymap = mcolors.LinearSegmentedColormap.from_list('my_colormap', colors, N=1*(2200+8578+13798))
ds = yt.load("plt000172380")
ad = ds.all_data()
products = ad.cut_region(['(obj["signed dist func"] < 0) & (obj["reactant mass frac"] < 0.5)']) # & (obj["y"] > 0.31)'])
ploc = products.quantities.max_location("x")
yH = ad.quantities.max_location("y")
yy = ploc - 0.5*yH #+ 0.3*yH
yy2 = yy.value
string = 'temperature' #schlieren
cut = ad.cut_region(['(obj["signed dist func"] < 0)'])# & (obj["temperature"] >= 1000.)'])
wide = 1.6 #1.6
height = 0.32 #0.32
if yy2 < wide/2.:
cent = wide/2.
cent = yy2
p = yt.ProjectionPlot(ds,2,string,center=[cent,height,0],width=(wide,height),origin="native",data_source=cut,method='integrate',weight_field='temperature')#,data_source=cut
p.set_colorbar_label(string, '') #'Temperature [K]')
p.set_cmap(field=string, cmap=mymap) #cmap='kamae_r') #'gray_r')