TRIQS / triqs

a Toolbox for Research on Interacting Quantum Systems
https://triqs.github.io
GNU General Public License v3.0
135 stars 71 forks source link

Partially revert c5b8670, restore k_space_path TPRF compat #904

Closed Wentzell closed 12 months ago

Wentzell commented 1 year ago

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?

HugoStrand commented 1 year 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:

https://triqs.github.io/tprf/unstable/user_guide/Square%20lattice%20susceptibility.html#Dispersion-\epsilon(\mathbf{k})-and-Fermi-surface

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.

HugoStrand commented 1 year ago

Here is the promised TPRF compatibility layer, https://github.com/TRIQS/tprf/commit/2a2010df68d6cddf76cd7e16595cc082bf0e0297

Wentzell commented 1 year ago

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.