re-order lattice vectors after importing.

[sliutheory]

I notice that seekpath will re-order the lattice vectors.
For example, if my QE input file has

CELL_PARAMETERS (angstrom)
5.511004561 0.0000000 -0.522914292
0.00000000 3.203286540 0.00000000
-0.833975125 0.00000000 9.033641976

Then after QE parsing:
v | x | y | z
v1 | -3.2032865400 | 0.0000000000 | 0.0000000000
v2 | 0.0000000000 | -1.6835747027 | 8.9144701514
v3 | 0.0000000000 | 5.5357574575 | 0.0000000000

Is there any reason to enforce such re-ordering?
Sometimes, I find such ordering quite inconvenient.

[tkotani]

Dear shippen,
I am a user of seekpath. This is because it only takes a,b,c,alpha,beta,gamma generated from
your given cell. When I start to use it, I also found it is inconvenient.

I myself wrote code for the matching process between your given cell and the standard cell.
Cell conversion matrix is the key. The code in embedded in my package ecalj --- you may
be able to see it at https://github.com/tkotani/ecalj/tree/master/GetSyml

[sliutheory]

Thanks! I will take a look at GetSyml.
But still, I feel it is better to have an option in kgetpath that allows users to fix the order of lattice vectors.

[giovannipizzi]

Dear @tkotani, what you say is not accurate. Seekpath also gets the 3x3 matrix of lattice vectors, and not only a,b,c,alpha,beta,gamma.

However, the fact that seekpath changes the lattice vectors is actually a feature and not a bug or an unintended side effect.
The need for standardising the cell is discussed in the paper and also in the docs.
This is both needed to simplify analysis of different crystal structures, but also to ensure for instance that a simulation code manages to use all symmetries (for instance, if you have a rhombohedral structure and you don't put the diagonal along a Cartesian axis but you put the first vector along x and the second on the xy plane, the symmetries of your system might not be compatible with those used by the code and the simulation might be much slower and less accurate (e.g. I know this is the case for Quantum ESPRESSO).

To conclude, I have an open issue (#16) to provide at least the matrix that brings the input vectors to the ones given in output by seekpath, that however requires some technicalities to be properly taken into account. Feel free to comment there if you think it's an essential feature.

[tkotani]

Dear Giovanni,
Thank you very much for your reply.
Standardizing is important, I agree.

But I think it may be another problem. We often
need to use non-standard primitive cell generated
from non-standard three primitive vectors.

I suppose this problem is just a matching problem between
(1) A Bravais lattice given by a,b,c,alpha,beta,gamma
(2) A Bravais lattice generated from three vectors for a primitive cell.
Here we need to imagine infinite and periodic Bravais lattices.
Note that Bravais lattice is an unique quantity independent from these representations.

Apparently, the three vectors of (2) do not necessarily directly give a,b,c,alpha,beta,gamma.
So I needed to think a little for the matching problem.
My code looks woring.

But I may need to think a little more...