shyuep
commented
6 years ago Thank you for the comprehensive report. However, I don't think you are doing the slabs right in VESTA. First of all, you can logically reason (without any code) that it is an impossibility that (102) is not equivalent to (012) in hexagonal systems. By definition, hexagonal systems have a 3/6-fold rotational symmetry. So anything that involves permutation of just the first two miller indices must result in symmetrically equivalent planes. In your case, you can simply think of it as the a direction in a hexagonal crystal is the same as the b direction.
I took the liberty of generating the (102) and (012) planes in the crystal, setting the d = 1. Download and open https://www.dropbox.com/s/wp1e0ii5zc8iskb/LNO.vesta?dl=0
You can quite clearly see that the two planes are equivalent.
MLars
wenhaosun
Dear community,
first of all I would like to thank you for the great work you put into the project. I started working with pymatgen a few months ago. I stumbled across the "bug" by accident and did quite some tests for verification.
The intention to use pymatgen was the availability of a slab generator for crystals in order to study surfaces of hexagonal crystals, namely LiNiO2, which is a common material for batteries. I am using VASP, so I attached a POSCAR file and also minimal script which is able to reproduce the bug.
Description of the bug Surfaces of crystals are characterized by their Miller index in the conventional standard cell. Some crystal surfaces and thus, also the corresponding Miller indices, are related to each other by symmetry operations. The provided script uses pymatgen to determine all distinct Miller indices of crystal surfaces up to a maximum index of 2. This is the result (just grep for "Miller" in the output and remove the Miller indices occurring twice): Miller index: (0, 0, 1) Miller index: (1, 0, 0) Miller index: (1, 0, 1) Miller index: (1, 1, 0) Miller index: (1, 1, 1) Miller index: (1, 0, 2) Miller index: (2, 0, 1) Miller index: (2, 1, 0) Miller index: (2, 1, 1) Miller index: (2, 2, 1) Miller index: (2, 1, 2) Miller index: (2, -1, 2)
I was particularly interested in the plane with Miller index (1,0,2) and (0,1,2). By cleaving the crystal along these planes (use e.g. VESTA and the conventional cell!) it is clearly visible, that both planes are completely different. (1,0,2) is kind of a vicinal surface, whereas (0,1,2) is terminated with either a (Li-Ni) plane or an Oxygen plane. (1,0,2) surface in the top left (green plane):
(0,1,2) surface in the top left (green plane):
So my basic question is, why the (0,1,2) surface is not found by the SlabGenerator?
Possible root cause of the faulty behavior: I did some more investigations and found out, that there are some symmetry operations that do not map the crystal onto itself. With the commands (to be used in the script attached to this report)
sga=SpacegroupAnalyzer(pin.structure)'conv=sga.get_conventional_standard_structure()'symm_ops = SpacegroupAnalyzer(conv).get_symmetry_operations()it is possible to analyze the symmetry operations. In particular the symmetry operation in real space ((1,-1,0),(1,0,0),(0,0,1)) (with some finite translation tau), which is in reciprocal space ((0,-1,0),(1,1,0),(0,0,1)) would map the Miller index (1,0,2) to (0,1,2). However, as stated above, these planes are not equivalent. So it might be possible that I (and maybe also the programmers of the SlabGenerator) do not fully understand how symmetry works or is implemented, or there is some kind of bug in the symmetry routines of pymatgen or, in the worst case, even in spglib.POSCAR file: POSCAR_LiNiO2.txt
script.py to generate slabs from crystals (please remove .txt): surface_minimal.py.txt
I would be very thankful for any feedback.
Best regards, Lars