Properties d3 input BAND section erroneously generated

[blokhin]

Relatively often the strange huge values are generated, e.g.:

BAND
CRYSTAL RUN
10 9007199254740992 30 1 76 1 0
0 0 0  0 4503599627370496 0
0 4503599627370496 0  0 4503599627370496 4503599627370496
0 4503599627370496 4503599627370496  0 0 4503599627370496
0 0 4503599627370496  0 0 0
0 0 0  -4503599627370496 0 4503599627370496
-4503599627370496 0 4503599627370496  -4503599627370496 4503599627370496 4503599627370496
-4503599627370496 4503599627370496 4503599627370496  0 4503599627370496 0
0 4503599627370496 0  -4503599627370496 4503599627370496 0
-4503599627370496 4503599627370496 0  -4503599627370496 0 0
-4503599627370496 0 0  0 0 0
NEWK
...

[ansobolev]

How the workchain is run? What is the input properties dict?

[blokhin]

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

[ansobolev]

Ok, I see it now. Can you please also give the CRYSTAL input that generates such fort.9 files?

[blokhin]

Yep, see attached.
f9_bands_error_calcs.zip

[ansobolev]

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.

[ansobolev]

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.

[ansobolev]

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.

[blokhin]

@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')

[blokhin]

Similar: KeyError: ('orthorhombic', 'C')

[ansobolev]

There are no such special k-points as A and C in CRYSTAL manual, see Tables 13.1 and 13.2 therein.

[blokhin]

How did they appear then? The structures are indeed orthorhombic.

Inconsistency between spglib and CRYSTAL manual may be?

[ansobolev]

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.

[blokhin]

Should I report to https://github.com/giovannipizzi/seekpath/issues?

[blokhin]

Please, could you update the SPECIAL_K with the new coordinates?

[ansobolev]

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.

[blokhin]

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

[blokhin]

KeyError: ('orthorhombic', 'A'): e.g.
GaP/63/oS8
InAs/63/oS8
Li2In/63/oS12
SeBr/41/oS16
SiO2/136/tP6 not orthorhombic at all

[blokhin]

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

[ansobolev]

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.