KPOINTS automatic generation, not quite commensurate

Something was odd when I used mcsqs to obtain some structures and converted them using runstruct_vasp -nr to VASP input format. It occasionally happens, one out of a few structures that goes very off.

The three division numbers are not quite commensurate with the cell lattice vectors.

The str.out looks like

4.000000 0.000000 0.000000
0.000000 4.000000 0.000000
0.000000 0.000000 4.000000
0.000000 0.000000 -2.000000
-1.000000 0.000000 -1.000000
2.500000 4.000000 3.500000
0.500000 1.500000 -1.000000 B
1.000000 2.500000 1.500000 C
0.500000 1.000000 -0.500000 B
-0.000000 1.500000 -1.500000 B
0.500000 1.500000 0.000000 B
1.000000 2.000000 0.000000 B
1.500000 2.500000 2.000000 C
1.000000 2.500000 0.500000 B
1.500000 3.000000 0.500000 B
2.000000 4.000000 1.000000 C
0.000000 1.000000 -1.000000 C
0.500000 1.000000 0.500000 B
-0.000000 1.500000 -0.500000 C
0.500000 2.000000 -0.500000 B
1.000000 2.000000 1.000000 B
1.500000 2.500000 1.000000 C
1.000000 3.000000 0.000000 C
1.500000 3.000000 1.500000 C
2.000000 3.500000 1.500000 B
1.500000 4.000000 0.500000 B
2.000000 4.000000 2.000000 C
-0.000000 0.500000 -1.500000 C
-0.000000 1.000000 -0.000000 B
0.500000 2.000000 0.500000 C
1.000000 3.000000 1.000000 C
1.500000 3.500000 1.000000 B
2.000000 3.500000 2.500000 C
1.500000 4.000000 1.500000 C
-0.500000 0.500000 -2.000000 B
-0.000000 0.500000 -0.500000 C
1.500000 3.500000 2.000000 B
-0.500000 0.500000 -1.000000 C
-0.000000 1.000000 -1.500000 N
0.500000 2.000000 -1.000000 N
0.000000 0.500000 -1.000000 N
0.500000 1.000000 -1.000000 N
-0.000000 1.000000 -0.500000 N
0.500000 1.500000 -0.500000 N
1.000000 2.000000 -0.500000 N
0.500000 2.000000 0.000000 N
1.000000 2.500000 0.000000 N
1.500000 3.500000 0.500000 N
-0.500000 0.500000 -1.500000 N
-0.000000 0.500000 0.000000 N
0.500000 1.000000 0.000000 N
-0.000000 1.500000 -1.000000 N
0.500000 1.500000 0.500000 N
1.000000 2.000000 0.500000 N
1.500000 2.500000 0.500000 N
1.000000 2.500000 1.000000 N
1.500000 3.000000 1.000000 N
2.000000 3.500000 1.000000 N
1.500000 3.500000 1.500000 N
2.000000 4.000000 1.500000 N
-0.500000 0.500000 -0.500000 N
-0.000000 1.500000 0.000000 N
1.500000 2.500000 1.500000 N
1.000000 3.000000 0.500000 N
1.500000 3.000000 2.000000 N
2.000000 3.500000 2.000000 N
1.500000 4.000000 1.000000 N
2.000000 4.000000 2.500000 N
1.000000 3.000000 1.500000 N
1.500000 4.000000 2.000000 N

The output KPOINTS divisions read [4,4,4].

In the package pymatgen, there is a function that does the same job: https://pymatgen.org/pymatgen.io.vaspio. … ic_density

It returns [4,6,2], which seems right.

The automatic k-point generation in ATAT takes into account the angles and lengths of the reciprocal lattice vectors. pymatgen only takes into account the lengths. 4 4 4 is more reasonable in your case (if your look, all nearest neighbors are at the same distance):

nnshell -l=str.out

I should add that your cell shape is not quite ideal because your lattice is orthorhombic based centered: there is a way to select your lattice vectors so that the true symmetry of the system is reflected in your choice of lattice vectors. To find it, do:

cellcvrt -fc < str.out

Ah, then the bug report case dismissed!

  1. I used to think reciprocal lattice vector length is the only factor here. So if one vector is particularly long (corresponding reciprocal lattice vector short), but there are still a lot of atoms in that direction, the division number should still not be too small?

  2. It’s in fact a structure generated from a rocksalt lat.in, with one sublattice randomized by B and C. The other one purely N (It doesn’t make much chemical sense but just an example). It’s random enough not to have any symmetry (P1), but why does the program think it’s oC? (VASP also thinks so, but it got me confused.)

I tried cellcvrt -sym and -ppg to the original str.out and the fixed str.out, both telling me space group/point group number is ‘1’. -pbv gives ‘oC’.

  1. What’s the benefit of fixing the cell? Does VASP work better/faster with a cell like that? Is it a preferred move after a mcsqs cell generation?

  2. Just to be sure. Does the cellcvrt -fc rotate the cell, or simply re-choose the lattice vectors? In this case, the cartesian coords do not not seem to change.