k path for the original cell without standardization

[jaemolihm]

As I discussed with @giovannipizzi during the Wannier 2022 developers meeting, I added two functions get_path_orig_cell and get_explicit_k_path_orig_cell, which does the same thing with the existing functions except that they keep the original cell: the original cell is not standardized or symmetrized.

The idea for the implementation is that linear combination of the lattice vectors does not change the 1st BZ, so only the real space rotations needs to be taken into account. I first implemented this idea in Brillouin.jl, a Julia implementation of the seekpath algorithm. For further information, see discussions in thchr/Brillouin.jl#15, thchr/Brillouin.jl#16.

If the input cell is a non-standard primitive unit cell, the returned k path is equivalent to the k path for the standard cell.
If the input cell is a supercell of a smaller primitive cell, the returned k path is that of the associated primitive cell, in the basis of supercell reciprocal lattice.

Example: silicon

• Non-standard unit cell is rotated by 17 degrees and the basis vectors are linearly combined.
• The supercell is a 1*1*2 supercell of the non-standard primitive cell.
• Standard and non-standard unit cell show identical band structures.
• Supercell band structure includes an identical copy of the primitive cell band structure and additional folded bands.
• Input files available in https://github.com/jaemolihm/seekpath_orig_cell_example
  

Tests

• TestPaths3D_HPKOT_Orig_Cell.base_test: Test the k path with and without standardization are equivalent up to rotation.
• TestPaths3D_HPKOT_Orig_Cell.test_no_symmetrization: Check that get_path_orig_cell does not symmetrize the input structure so that for a slightly distorted system the k points are not exactly on the high-symmetry points
• TestExplicitPaths_Orig_Cell.test_keys: Test output keys of get_explicit_k_path_orig_cell
• TestExplicitPaths_Orig_Cell.test_path: Test the explicit k point list for with and without standardization are equivalent up to rotation.

[jaemolihm]

This PR does not "Provide Transformation Matrix as output of the code" which is the title of issue #16, but it solves the related issue of calculating the k path for keeping the input structure (#77, aiidateam/aiida-core#4391 (comment)).

The difference with the approach in branch fix_transformation_matrix is that this PR applies rotation in the Cartesian coordinates, while that branch tries to apply transformation matrix in the scaled (=crystal=reduced) coordinates. The latter is more complicated to implement because seekpath uses different linear combination of lattice vectors to spglib.

[tkotani]

This is what I implemented several years ago.
As you noticed, we have to find out unimodular matrix which connects two sets of primitive vectors.
FYI: Related to "lattice encryption", we don't have very efficient way to find out the unimodular matrix.
Some trial and error procedure needed, I think. (this is what I had implemented).
Math of integer matrix is not so easy to handle.

[jaemolihm]

This is what I implemented several years ago. As you noticed, we have to find out unimodular matrix which connects two sets of primitive vectors. FYI: Related to "lattice encryption", we don't have very efficient way to find out the unimodular matrix. Some trial and error procedure needed, I think. (this is what I had implemented). Math of integer matrix is not so easy to handle.

Dear @tkotani , thanks for the comments. To be clear, I did not calculate or use the integer-valued unimodular matrix. Instead, I used the orthogonal rotation matrix that describes the real-space rotation (std_rotation_matrix of spglib).

Here, I do not need the integer-valued matrix at all. If in the future one wants it for some reason, one can use L_std = R * L_inp * N (L_std: standard primitive lattice, L_inp: input lattice, R: orthogonal rotation matrix, N: integer-valued unimodular matrix). Since L_std, R, L_inp are known, N can be easily computed.

[tkotani]

Dear @jaemolihm, Thank you for your reply. I see.
Generally speaking, the same lattice is defined by different sets of primitive vectors.
The sets are related by unimodular matrix.

See https://cseweb.ucsd.edu/classes/wi12/cse206A-a/lec1.pdf
Theorem 4. (page 2.) is what I said. We have to find out the matrix U.

[giovannipizzi]

Suggested change

	of the supercell reciprocal lattice vectors. In this case, the k point
	labels lose their meaning: they are not at the high-symmetry points of
	the first BZ of the given supercell.
	of the supercell reciprocal lattice vectors. Note that, in this case,
	the k-point labels are not at the high-symmetry points of
	the first BZ of the given supercell.

[jaemolihm]

I did a slightly modified version: "In this case, the k-point labels lose their meaning as the corresponding k-points are not at the high-symmetry"

[giovannipizzi]

Copy the same comment as in the other function ("If the provided unit cell is a supercell...") so the docstrings are the same?

[jaemolihm]

Done

[jaemolihm]

I locally tested with spglib-2.0.2 and tests passed.

[giovannipizzi]

Thanks! I fixed the test system, but I upgraded packages such as pre-commit and black. You'd need to rerun black and then it's good to go! (Also wrote you on slack with more details, if needed) OK, I have edit permissions on this branch. Let's see if the additional commit worked.

[giovannipizzi]

Thanks a lot, looks great!

[jaemolihm]

Thanks a lot for the review!