Closed Wentzell closed 12 months ago
I disagree with the statement. I would like the tick positions returned to be all high symmetry points in the plot, so that the returned vector can be passed directly to a plt.ticks(...)
call, see below.
Please note that this is a new and optional feature that I have added, so we do not yet have TRIQS users using this.
Including the first and last point will enable cleaner examples in the documentation by removing the np.concatenate
clutter we currently have here for example:
With the proposed change the code is simplified to
G = [0.0, 0.0, 0.0]
X = [0.5, 0.0, 0.0]
M = [0.5, 0.5, 0.0]
path = [(G, X), (X, M), (M, G)]
from triqs.lattice.utils import k_space_path
k_vecs, k_plot, k_ticks = k_space_path(
path, num=32, bz=H_r.bz,
relative_coordinates=False, return_ticks=True)
e_k_interp = np.vectorize(lambda k : e_k(k).real, signature='(n)->()')
plt.plot(k_plot, e_k_interp(k_vecs))
plt.xticks(k_ticks, labels=[r'$\Gamma$', '$X$', '$M$', r'$\Gamma$']) # Here can pass k_ticks directly without additional operations.
plt.ylabel(r'$\epsilon(\mathbf{k})$')
plt.grid(True)
This produces the standard kind of high-symmetry path figure as in the example above.
I want this for the TRIQS tutorials next week.
While I wait for this pull request I will add a compatibility layer in TPRF so that I can finish the tutorials.
Here is the promised TPRF compatibility layer, https://github.com/TRIQS/tprf/commit/2a2010df68d6cddf76cd7e16595cc082bf0e0297
Thank you @HugoStrand @the-hampel for clarifying. I agree with the points you made.
In that case the calculation of the ticks is more involved than just doing dist[num:num]
, which was the initial reason I decided not to return them. I iterated to commit and changed it to always return the ticks.
Suggestion by @HugoStrand, to be discussed.
I think the API is less clear this way, ticks should contain the actual tick positions along the way and not the edges?