Closed blokhin closed 4 years ago
How the workchain is run? What is the input properties
dict?
A wrong kpath
is obtained from a structure extracted from a correctly saved fort.9
:
wf = Fort9('fort.9')
structure = wf.get_structure()
_, __, kpath = get_shrink_kpoints_path(structure)
kpath
[[[0, 0, 0], [0, 9007199254740992, 0]], [[0, 9007199254740992, 0], [0, 9007199254740992, 9007199254740992]], [[0, 9007199254740992, 9007199254740992], [0, 0, 9007199254740992]], [[0, 0, 9007199254740992], [0, 0, 0]], [[0, 0, 0], [-9007199254740992, 0, 9007199254740992]], [[-9007199254740992, 0, 9007199254740992], [-9007199254740992, 9007199254740992, 9007199254740992]], [[-9007199254740992, 9007199254740992, 9007199254740992], [0, 9007199254740992, 0]], [[0, 9007199254740992, 0], [-9007199254740992, 9007199254740992, 0]], [[-9007199254740992, 9007199254740992, 0], [-9007199254740992, 0, 0]], [[-9007199254740992, 0, 0], [0, 0, 0]]]
Note the coordinates are huge (and always the same). I attach two such fort.9
files, but there are many.
f9_bands_error.zip
Ok, I see it now. Can you please also give the CRYSTAL input that generates such fort.9 files?
Yep, see attached. f9_bands_error_calcs.zip
In fact this is a result of two bugs, both of which are connected to the lack of machine precision. The first bug is due to the fact that there is no way to correctly represent 1/3 as the floating point number. There are special points in Brillouin zone for hexagonal lattice with coordinates equal to 1/3; however, exact representation of the fraction is impossible in the FP arithmetic, and hence it's approximated using the fraction with large numerator and denominator, giving large shrink factors. Now I approximate the coordinate with the fraction with the smallest denominator; this should do it.
However, there is one more bug due to limited precision of writing geometry to fort.9. Because of that, cell vectors that are read from fort.9 are not the same as in fort.34, and hence, the angles between vectors are incorrect and the information about symmetry is lost. To solve the problem it seems necessary to pass the correct structure (i.e. the one from fort.34) to get_shrink_kpoints_path
.
Even in this case there will be a problem with fort.25 parser, as it relies upon the struvture from fort.9 to populate BandsData
object.
@ansobolev is this related? SPECIAL_K collection contains no A for the orthorhombic lattice:
File "/usr/local/lib/python3.7/dist-packages/mpds_aiida/properties.py", line 181, in run_properties_direct
path_description = construct_kpoints_path(cell, path, shrink, k_number)
File "/usr/local/lib/python3.7/dist-packages/aiida_crystal_dft/utils/kpoints.py", line 179, in construct_kpoints_path
special_k = {v: k for k, v in get_special_kpoints(sg_symbol, sg_number).items()}
File "/usr/local/lib/python3.7/dist-packages/aiida_crystal_dft/utils/kpoints.py", line 125, in get_special_kpoints
return SPECIAL_K[(lattice, symbol[0])]
KeyError: ('orthorhombic', 'A')
Similar: KeyError: ('orthorhombic', 'C')
There are no such special k-points as A and C in CRYSTAL manual, see Tables 13.1 and 13.2 therein.
How did they appear then? The structures are indeed orthorhombic.
Inconsistency between spglib
and CRYSTAL manual may be?
That's a seekpath
issue, it seems that sometimes they return a path with non-conventional point labels. However, they also return a dict with the coordinates for the given points; it seems that we can use this dict to construct the path for CRYSTAL.
Should I report to https://github.com/giovannipizzi/seekpath/issues?
Please, could you update the SPECIAL_K with the new coordinates?
Can you give the example of structure that leads to such points generation? Here there are many points listed; A and C are there, their coordinates depend on some alpha. That means that it's not possible to add the points to SPECIAL_K directly, their coordinates will depend on structure, and some post-processing should be done on them.
KeyError: ('orthorhombic', 'C')
: e.g.
BrCl/36/oS8
BrF3/36/oS16
InCl/63/oS8
ScGe/63/oS8
AlSb/63/oS8
Li7Ge2/65/oS36
OCO/64/oS12
KeyError: ('orthorhombic', 'A')
: e.g.
GaP/63/oS8
InAs/63/oS8
Li2In/63/oS12
SeBr/41/oS16
SiO2/136/tP6 not orthorhombic at all
Unfortunately, the bug still persists:
BAND
CRYSTAL RUN
11 372400 80 1 208 1 0
0 0 0 186200 -186200 186200
186200 -186200 186200 116237 -116237 256162
-116237 116237 116237 0 0 0
0 0 0 119281 119281 -119281
253118 -119281 119281 186200 -186200 186200
0 0 0 0 186200 0
0 186200 0 93100 93100 93100
93100 93100 93100 186200 0 0
186200 0 0 0 0 0
0 0 0 0 0 186200
0 0 186200 93100 93100 93100
NEWK
6 6
...
The optimization producing the fort.34
and fort.9
is attached.
5050-0102-4cdb-add9-f6c2890ba2e8.zip
That's not a bug but rather unconventional way of introducing fractional coordinates implemented in CRYSTAL. They put coordinates as ordinary fractions, with shrinking factor as denominator (eg, 186200/372400). As long as symmetries are common, the coordinates of high symmetry points are represented as small fractions. In crystals with not so common symmetry high symmetry points can have irrational coordinates. They cannot be represented with ordinary fractions.
Relatively often the strange huge values are generated, e.g.: