@JuliaRegistrator register

Is there any particular reason why src/magnetic.jl is not actually included. I would love to use get_symmetry_with_collinear_spin in DFTK.

Hi, I think I spotted a bug here - the original spglib niggli_reduce function work on the lattice. When reducing the structure, the cartesian coordinates that should be preserved not the fraction coordinates.

But here the fraction coordinates are copied over instead, giving incorrect results. One can easily verify by checking if the distances between atoms are kept after the reduction.

@JuliaRegistrator register()

Or it will throw errors?

@JuliaRegistrator register()

@JuliaRegistrator register()

I would expect the following code to run cleanly, but it throws a BoundsError:

import Spglib
latvecs = [6.42 0 0; 0.0 6.41 0; 0.0 0.0 6.44]
x = 0.79
y = 1-x
positions = [[y, y, x], [y, x, y], [x, y, y], [x, x, x], [x, x, y], [x, y, x], [y, x, x], [y, y, y]]
types = ["Ga", "Ga", "Ga", "Ga", "Ga", "Ga", "Ga", "Ga"]
cell = Spglib.Cell(latvecs, positions, types)
Spglib.get_dataset(cell, 1e-3) # BoundsError

Stacktrace:

ERROR: BoundsError: attempt to access 26-element StepRange{Char, Int64} at index [27]
Stacktrace:
 [1] throw_boundserror(A::StepRange{Char, Int64}, I::Int64)
   @ Base ./abstractarray.jl:734
 [2] getindex
   @ ./range.jl:948 [inlined]
 [3] (::Spglib.var"#7#12")(w::Int32)
   @ Spglib ./none:0
 [4] iterate
   @ ./generator.jl:47 [inlined]
 [5] collect(itr::Base.Generator{Vector{Int32}, Spglib.var"#7#12"})
   @ Base ./array.jl:834
 [6] Spglib.Dataset(dataset::Spglib.SpglibDataset)
   @ Spglib ~/.julia/packages/Spglib/O9RSC/src/core.jl:352
 [7] get_dataset(cell::Spglib.SpglibCell{Float64, Float64, String, Any}, symprec::Float64)
   @ Spglib ~/.julia/packages/Spglib/O9RSC/src/symmetry.jl:175
 [8] top-level scope
   @ REPL[8]:1

The code runs without error when (a) the symmetry precision is reduced to 1e-2 or (b) the unit cell is cubic or (c) any atom is removed.

Versions

Tested on Spglib v0.9.1, with:

julia> versioninfo()
Julia Version 1.10.0-rc3
Commit ed79752b939 (2023-12-18 09:57 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin22.4.0)
  CPU: 8 × Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
  Threads: 1 on 6 virtual cores

Different symprec will have different results in different functions, even for the same crystal structure.
That would be surprising. We do not want that.

Hi! First, off, thanks for the port to Julia! It is super useful for my research! (:

Describe the bug
For a crystal with trigonal spacegroup symmetry, Spglib fails to reshape the unit cell to accommodate the symmetry equivalent settings of the spacegroup. Case in point, the spacegroup 148 with setting 1. Hall number 436 according to https://yseto.net/sg/sg1

To Reproduce
Steps to reproduce the behavior:

1. Start Julia REPL

2. Run:

using Spglib
basis_v = [7 -3.5 0; 0 6.06218 0; 0 0 19]
positions = [[0.0, 0.0, 1/6]]
atoms = [1]
cell = Cell(basis_v, positions, atoms)
ds = get_dataset_with_hall_number(cell, 436, 1e-5)

Note: I have tried relaxing the symmetry precision parameter to no avail.

3. See error ERROR: SpglibError: spacegroup search failed!

Expected behavior
The ds object should be consistent with what is expected for spacegroup 148 with the rhombohedral setting.

Versions (please complete the following information):

• OS: Ubuntu 22.04 Jammy under WSL.
• Julia version: 1.10.1
• Spglib: v0.9.3

Currently, it follows the C-indexing style, starting from 0. But it's not Julia style.

Dear Spglib.jl users,

I would like to inform you of a recent issue encountered with Spglib.jl following an upgrade to spglib_jll.jl version v2.2.0+0. Some tests have failed post-upgrade, indicating potential compatibility or functional issues.

Upon initial investigation, I observed that corresponding Python code in Spglib has also undergone changes. This leads me to believe that the root of the problem might lie within the changes made to Spglib's underlying C code, rather than being specific to spglib_jll.jl & Spglib.jl alone.

Currently, I am unable to allocate time to debug this issue in detail. My next step is to reach out to the official Spglib development team for insights and possible solutions.

In the meantime, I recommend that users revert spglib_jll.jl to version v2.1.0+0 to ensure stability and avoid the issues presented by the latest update. I apologize for any inconvenience caused and appreciate your patience and understanding as we work towards resolving this matter.

Thank you for your cooperation.

@JuliaRegistrator register

The current implementation have multiple error types if the exit code of spglib is 0:

We should unify them as suggested by this post. Thus, we decide to add a type named SpglibError, the same as what's defined in spglib.

The following will segfault:

lat_vecs = [4.05 -2.025 0.0; 0.0 3.507402885326976 0.0; 0.0 0.0 6.76]
positions = [0.6666 0.3333 0.75; 0.6667 0.3334 0.75]'
symprec = 1e-3
cell = Spglib.Cell(lat_vecs, positions, [1, 1])
d = Spglib.get_dataset(cell, symprec) # crashes

The problem is that the unit cell is invalid for symprec=1e-3, and spg_get_dataset() returns NULL. However, the Spglib.jl bindings do not handle the NULL case here: https://github.com/singularitti/Spglib.jl/blob/master/src/symmetry.jl#L259

In case of failure, it seems most appropriate for Spglib.get_dataset to return nothing.

Hi, thanks for this nice package!

I would like to ask what do you think about making following changes to the Cell struct.

1. Allow magmom to be nothing (nonmagnetic), Vector{T} (collinear), and Vector{MVector{3,M}} (noncollinear).
2. Use Vector{MVector{3,P}} instead of MMatrix{3,N,P} for position. The latter causes type instability when constructing Cell. (This was also suggested in #84)

Now we can have a new version!

I have already avoided using spglib_jll 2.2.0. The following code is directly copied from tests.

pkg> add Spglib spglib_jll@2.1.0
   Resolving package versions...
  [f761d5c5] + Spglib v0.9.3
⌃ [ac4a9f1e] + spglib_jll v2.1.0+0
⌅ [80545937] + CrystallographyCore v0.3.3
  [f761d5c5] + Spglib v0.9.3
  [6ec83bb0] + StructEquality v2.1.0
  [8e1ec7a9] + SumTypes v0.5.5
⌃ [ac4a9f1e] + spglib_jll v2.1.0+0
        Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
Precompiling project...
  2 dependencies successfully precompiled in 3 seconds. 92 already precompiled.

julia> using Spglib

julia> lattice = [[7.17851431, 0, 0], [0, 3.99943947, 0], [0, 0, 8.57154746]]
3-element Vector{Vector{Float64}}:

 [7.17851431, 0.0, 0.0]
 [0.0, 3.99943947, 0.0]
 [0.0, 0.0, 8.57154746]

julia> positions = [
           [0.0, 0.84688439, 0.1203133],
           [0.0, 0.65311561, 0.6203133],
           [0.0, 0.34688439, 0.3796867],
           [0.0, 0.15311561, 0.8796867],
           [0.5, 0.34688439, 0.1203133],
           [0.5, 0.15311561, 0.6203133],
           [0.5, 0.84688439, 0.3796867],
           [0.5, 0.65311561, 0.8796867],
       ]
8-element Vector{Vector{Float64}}:
 [0.0, 0.84688439, 0.1203133]
 [0.0, 0.65311561, 0.6203133]
 [0.0, 0.34688439, 0.3796867]
 [0.0, 0.15311561, 0.8796867]
 [0.5, 0.34688439, 0.1203133]
 [0.5, 0.15311561, 0.6203133]
 [0.5, 0.84688439, 0.3796867]
 [0.5, 0.65311561, 0.8796867]

julia> atoms = fill(8, length(positions))
8-element Vector{Int64}:
 8
 8
 8
 8
 8
 8
 8
 8

julia> cell = Cell(lattice, positions, atoms)
SpglibCell{Float64, Float64, Int64, Any}
 lattice:
   7.17851431  0.0  0.0
   0.0  3.99943947  0.0
   0.0  0.0  8.57154746
 8 atomic positions:
   0.0  0.84688439  0.1203133
   0.0  0.65311561  0.6203133
   0.0  0.34688439  0.3796867
   0.0  0.15311561  0.8796867
   0.5  0.34688439  0.1203133
   0.5  0.15311561  0.6203133
   0.5  0.84688439  0.3796867
   0.5  0.65311561  0.8796867
 8 atoms:
   8  8  8  8  8  8  8  8


julia> primitive_cell = find_primitive(cell)
Unreachable reached at 0x7fa4b5c87ac3

Julia info:

julia> versioninfo()
Julia Version 1.10.0
Commit 3120989f39b (2023-12-25 18:01 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 40 × Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, cascadelake)
  Threads: 1 on 40 virtual cores
Environment:
  JULIA_PKG_USE_CLI_GIT = true

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

@JuliaRegistrator register

We have noticed intermittent crashes since upgrading from Spglib 0.9.2 to 0.9.3. Looks like the only real difference between these versions is the switch from enums to SumTypes: 819b7f6.

It appears that there is memory corruption when reading an spglib_jll response into a sum type, and this has been confirmed @MasonProtter on the SumTypes repo: MasonProtter/SumTypes.jl#71

This isn't a bug with SumTypes, it's just being used in a completely invalid way by that library. It's asserting to julia that it can interpret the return type from a ccall as a sum type, which encloses a union, so yeah that's almost guaranteed to cause memory corruption.

The error could appear as a segfault or some other error. First found on our Github actions CI with Julia 1.9.4, Ubuntu, x86: https://github.com/SunnySuite/Sunny.jl/actions/runs/7629267203/job/20782289111?pr=217

I haven't seen the crashes yet on my Mac. On Linux/x86, reproducing might be as simple as ] add Sunny#spglib_crash and then using Sunny.

@JuliaRegistrator register()

Describe the bug
find_primitive results in the error message "ERROR: ambiguous positions size 3×3! Use a vector of Vectors instead!"
in some cases where the result has 3 atoms.

To Reproduce
Steps to reproduce the behavior:
using Spglib
A = [6.0 0 6; 6 0 6; 0 6 6]
coords = [0.0 0.0 0.0;0.5 0.5 0.5; 0.75 0.75 0.75]
coords_vec = [coords[i,:] for i in 1:3]
atoms = ["Na", "Cl", "Na"]
cell = Spglib.Cell(A, coords_vec, atoms) #results in error

#also results in error
cell_std = Spglib.standardize_cell(cell, to_primitive=true)

Describe the bug
I don't know whether it's a bug or a feature, but standardize_cell erases off the atomic number information of the cell passed to it: thus suppose we have

julia> TaSe2_1T_cell.atoms
3-element Vector{Int64}:
 73
 34
 34

and we get

julia> refine_cell(TaSe2_1T_cell, 1e-3).atoms
3-element Vector{Int32}:
 1
 2
 2

To Reproduce
Steps to reproduce the behavior:

1. Start Julia REPL
2. Construct whatever a Cell
3. Run standardize_cell(cell).atoms, and you will find it's an array consisting of numbers 1, 2, 3, etc. which distinguish different atoms but tell us nothing about what these atoms actually are.

Expected behavior

standardize_cell(cell).atoms == cell.atoms

Additional context
The cause of the behavior is that at the end of standardize_cell(cell::AbstractCell, symprec=1e-5; to_primitive=false, no_idealize=false), the atoms field of the return value is set to atoms[1:num_atom_std]. The definition of atoms is

lattice, _positions, _atoms = _expand_cell(cell)
# ...
atoms = Vector{Cint}(undef, num_atom * allocations)
# ...
atoms[1:num_atom] .= _atoms

And if we go to the function _expand_cell, we find the following lines:

atoms = collect(Cint, findfirst(isequal(u), unique(atoms)) for u in atoms)
# ...
return lattice, positions, atoms, magmoms

So indeed _atoms (hence standardize_cell(cell).atoms) in standardize_cell contains the aforementioned indices 1, 2, 3, etc. which distinguish different atoms but tell us nothing about what these atoms actually are.

I don't know if there is any reason to not set standardize_cell(cell).atoms to cell.atoms aftrer everything is finished.