Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes site symmetry can't be inferred #44

Open
kbarros opened this issue Sep 26, 2022 · 5 comments · May be fixed by #325
Open

Sometimes site symmetry can't be inferred #44

kbarros opened this issue Sep 26, 2022 · 5 comments · May be fixed by #325

Comments

@kbarros
Copy link
Member

kbarros commented Sep 26, 2022

In this example,

a = b = 4.05012  # angstroms
c = 6.75214
lat_vecs = lattice_vectors(a, b, c, 90, 90, 120)
Crystal(lat_vecs, [[0,0,0]], 164; types=["Fe"])

Sunny builds the correct crystal, but cannot infer the site symmetry. The output is:

Crystal
HM symbol 'P -3 m 1' (164)
Lattice params a=4.05, b=4.05, c=6.752, α=90°, β=90°, γ=120°
Cell volume 95.92
Type 'Fe':
   1. [0, 0, 0]

However, if we also include the iodine atoms, then

Crystal(lat_vecs, [[0,0,0], [1/3, 2/3, 1/4]], 164; types=["Fe", "I"])

correctly outputs:

Crystal
HM symbol 'P -3 m 1' (164)
Lattice params a=4.05, b=4.05, c=6.752, α=90°, β=90°, γ=120°
Cell volume 95.92
Type 'Fe', Wyckoff 1a (point group '-3m.'):
   1. [0, 0, 0]
Type 'I', Wyckoff 2d (point group '3m.'):
   2. [0.3333, 0.6667, 0.25]
   3. [0.6667, 0.3333, 0.75]

which indicates the point group of -3m. for Fe.

The latter works by asking Spglib to infer all symmetry information about the crystal cell. From what I can tell, Spglib has no functionality to report point group symmetry information for a position and a given Hall number. See, e.g., spglib/spglib#135.

@kbarros
Copy link
Member Author

kbarros commented Sep 26, 2022

Another caution is that the Spglib documentation states this:

[Site symmetry symbols] are valid for the standard settings. For different settings and choices belonging to the same space group type, the same set of the symbols is returned.

Source. It's not clear to me whether this means that the returned symbols could be invalid for non-standard settings?

@kbarros
Copy link
Member Author

kbarros commented Aug 25, 2023

The same problem arose in a surprising way for Na4Ir3O8 (the iridium are arranged in a hyperkagome here)

a = 8.981
latvecs = lattice_vectors(a, a, a, 90, 90, 90)

x = 0.141
p = [0.125, x, x+1/4]
cryst = Crystal(latvecs, [p], 213) # Wyckoff 12d, point group ..2
@assert !isnothing(cryst.sitesyms)

x = 0
p = [0.125, x, x+1/4]
cryst = Crystal(latvecs, [p], 213) # Site symmetry is the same, but can't be inferred
@assert isnothing(cryst.sitesyms)

In the special case of x = 0, it appears that spglib needs more crystallographic information to infer the spacegroup symmetry 213, and our "hack" breaks.

@kbarros kbarros added the wontfix This will not be worked on label Aug 27, 2023
@kavanase
Copy link

kavanase commented Mar 3, 2024

Just noting I mentioned the symmetry/Wyckoff analysis functions in doped which could possibly be used for this goal in spglib/spglib#135

@kbarros
Copy link
Member Author

kbarros commented Mar 4, 2024

This looks great, thanks for sharing! I wonder if the logic could be ported into Sunny/Julia without too much trouble.

@kbarros kbarros added help wanted Extra attention is needed and removed wontfix This will not be worked on labels Mar 4, 2024
@kbarros
Copy link
Member Author

kbarros commented Jun 8, 2024

If the chemical cell is known to be "conventional" for the given space group (in the sense of the Bilbao server), then it is possible to look up the data from tables, e.g., as available from the wyckoffs function of Crystalline.jl: https://thchr.github.io/Crystalline.jl/dev/api/#Crystalline.wyckoffs-Union{Tuple{Integer},%20Tuple{D},%20Tuple{Integer,%20Val{D}}}%20where%20D

@kbarros kbarros removed the help wanted Extra attention is needed label Aug 19, 2024
@kbarros kbarros linked a pull request Oct 10, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants