spglib-users

[Spglib-users] Introduction and CASTEP

[Keith R. <kr...@gm...>]

Hello,

I would like to introduce myself as one of the developers of the CASTEP 
DFT materials modelling code.   We plan to replace some old space group 
symmetry analysis code with spglib.

My initial tests are proving very positive about the capabilities of 
spglib for this purpose.

1) There is one piece of missing functionality we need.  This would be
    a routine similar to spg_get_dataset() but which takes as input a
    list of symmetry operations, not the lattice and co-ordinates. This
    would be to analyse a pre-supplied set of operations (rotation
    matrices and translations).  How hard would it be to add this?

2) May I ask how spglib handles non-primitive supercells. If,
    for example you were to pass a lxmxn block of primitive cells would
    spglib return the complete product group of the translation and
    rotation groups?  This is important because if only the rotation
    subset were specified the set of operations do not form a complete
    group. (As atoms can be mapped between different primitive cells).

3) Is there any built-in test whether the symmetry operations form a
    group?

sincerely

Keith Refson

Re: [Spglib-users] Introduction and CASTEP

[Atsushi T. <atz...@gm...>]

Hello,

I'm a developer of spglib.

1) I think it's not a very hard work. lattice parameters are necessary
to be supplied for hal_get_hall_symbol, but for this purpose, just
dummy lattice parameters should be OK.
2) If I understand correctly, what usually obtained as symmetry
operations are not a space group, but coset representatives, which may
not form a group in the case of non-symmorphic crystals. For an lxmxn
supercell, spglib returns the coset representatives (or symmetry
operations) x a set of pure translations of lxmxn. In addition, the
point group of the lattice parameters given for the supercell is not
the same as that of primitive cell, then the symmetry is given lower,
i.e. 2x1x1 of cubic is not treated as cubic symmetry x pure
translations, but tetragonal symmetry x pure translations.
3) The symmetry operations are internally compared with database of
space group types, and if the operations can be a space group type,
the tolerance parameter to be used for symmetry operation search is
adjusted (usually only reduced) until the symmetry operations will be
OK.

Best regards,

Togo

On Wed, Mar 26, 2014 at 10:37 PM, Keith Refson <kr...@gm...> wrote:
> Hello,
>
> I would like to introduce myself as one of the developers of the CASTEP
> DFT materials modelling code.   We plan to replace some old space group
> symmetry analysis code with spglib.
>
> My initial tests are proving very positive about the capabilities of
> spglib for this purpose.
>
> 1) There is one piece of missing functionality we need.  This would be
>     a routine similar to spg_get_dataset() but which takes as input a
>     list of symmetry operations, not the lattice and co-ordinates. This
>     would be to analyse a pre-supplied set of operations (rotation
>     matrices and translations).  How hard would it be to add this?
>
> 2) May I ask how spglib handles non-primitive supercells. If,
>     for example you were to pass a lxmxn block of primitive cells would
>     spglib return the complete product group of the translation and
>     rotation groups?  This is important because if only the rotation
>     subset were specified the set of operations do not form a complete
>     group. (As atoms can be mapped between different primitive cells).
>
> 3) Is there any built-in test whether the symmetry operations form a
>     group?
>
> sincerely
>
> Keith Refson
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Spglib-users mailing list
> Spg...@li...
> https://lists.sourceforge.net/lists/listinfo/spglib-users



-- 
Atsushi Togo
http://atztogo.github.com/
atz...@gm...

[Spglib-users] Case where symmetry displacements are wrong.

[Keith R. <kr...@gm...>]

My tests of spglib have turned up a case where it seems that spglib is 
returning an incorrect result.  In the attached case, spglib returns an 
identical set of symmetry rotations to the old K290 symmetry analysis.
However the non-symmorphic translations are different and, I believe 
wrong for all of the 3-fold axes in the attached example.  In particular 
any attempt to construct an atom-atom map for the 3-fold and -3 
operations fails.

Do you agree that this is a bug in spglib?

Keith

Re: [Spglib-users] Case where symmetry displacements are wrong.

[Atsushi T. <atz...@gm...>]

I can't see if it is wrong or not from your files. What is the K290?
The definition of rotation matrix is the same (could be trasposed)?

Togo

On Fri, Mar 28, 2014 at 8:45 PM, Keith Refson <kr...@gm...> wrote:
> My tests of spglib have turned up a case where it seems that spglib is
> returning an incorrect result.  In the attached case, spglib returns an
> identical set of symmetry rotations to the old K290 symmetry analysis.
> However the non-symmorphic translations are different and, I believe wrong
> for all of the 3-fold axes in the attached example.  In particular any
> attempt to construct an atom-atom map for the 3-fold and -3 operations
> fails.
>
> Do you agree that this is a bug in spglib?
>
> Keith
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Spglib-users mailing list
> Spg...@li...
> https://lists.sourceforge.net/lists/listinfo/spglib-users
>



-- 
Atsushi Togo
http://atztogo.github.com/
atz...@gm...

Re: [Spglib-users] Case where symmetry displacements are wrong.

[Keith R. <kr...@gm...>]

Dear Togo,

Aha, that was it! The rotation matrices were transposed which 
effectively switched the translations making them inconsistent.

Thank you for the hint!

sincerely

Keith Refson

On 28/03/14 12:08, Atsushi Togo wrote:
> I can't see if it is wrong or not from your files. What is the K290?
> The definition of rotation matrix is the same (could be trasposed)?
>
> Togo
>
> On Fri, Mar 28, 2014 at 8:45 PM, Keith Refson <kr...@gm...> wrote:
>> My tests of spglib have turned up a case where it seems that spglib is
>> returning an incorrect result.  In the attached case, spglib returns an
>> identical set of symmetry rotations to the old K290 symmetry analysis.
>> However the non-symmorphic translations are different and, I believe wrong
>> for all of the 3-fold axes in the attached example.  In particular any
>> attempt to construct an atom-atom map for the 3-fold and -3 operations
>> fails.
>>
>> Do you agree that this is a bug in spglib?
>>
>> Keith
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Spglib-users mailing list
>> Spg...@li...
>> https://lists.sourceforge.net/lists/listinfo/spglib-users
>>
>
>
>

[Spglib-users] Determine spacegroup given symmetry operations

[Keith R. <kr...@gm...>]

Hi,

I'd like to pick up on a question I raised a couple of years ago, as an
enhancement
to the spglib API.

The functionality I need is to pass a lattice and set of symmetry operations
as input parameters and obtain the space group - for example as an
SpglibDataset. 
Specifically the atomic co-ordinates are NOT to be used to determine the
symmetries.

The reason for this is for use in electronic structure codes in the
presence of symmetry-breaking.
It is commonly necessary to work in a subgroup, where the symmetry is
broken by, for example,
a magnetic structure, an anisotropic external stress or an electric
field or atomic displacement
perturbation, or a supercell where the supercell lattice vectors do not
transform invariantly under
the full point group.  The idea is that the caller works out the
remaining symmetries belonging to the
subgroup and passes these as input.

Following your hint and looking at the code, this does not look 
difficult in principle.  But there are
API design issues which I don't feel qualified to make.  And for
maintenance reasons it would be
best if any change was incorporated into future spglib releases.

Is it realistic to request an enhancement to spglib to do this?

sincerely

Keith Refson


On 27/03/14 04:44, Atsushi Togo wrote:
> Hello,
>
> I'm a developer of spglib.
>
> 1) I think it's not a very hard work. lattice parameters are necessary
> to be supplied for hal_get_hall_symbol, but for this purpose, just
> dummy lattice parameters should be OK.

Re: [Spglib-users] Determine spacegroup given symmetry operations

[Atsushi T. <atz...@gm...>]

Hi,

It's a nice feature.

If the symmetry operations and lattice parameters are those for the
primitive cell, it will be very easy (I supposed this case before). If
not, some more implementation is necessary. But in principle, as an
input, lattice parameters are unnecessary. I will think.

Togo

On Wed, Apr 6, 2016 at 6:01 PM, Keith Refson <kr...@gm...> wrote:
> Hi,
>
> I'd like to pick up on a question I raised a couple of years ago, as an
> enhancement
> to the spglib API.
>
> The functionality I need is to pass a lattice and set of symmetry operations
> as input parameters and obtain the space group - for example as an
> SpglibDataset.
> Specifically the atomic co-ordinates are NOT to be used to determine the
> symmetries.
>
> The reason for this is for use in electronic structure codes in the
> presence of symmetry-breaking.
> It is commonly necessary to work in a subgroup, where the symmetry is
> broken by, for example,
> a magnetic structure, an anisotropic external stress or an electric
> field or atomic displacement
> perturbation, or a supercell where the supercell lattice vectors do not
> transform invariantly under
> the full point group.  The idea is that the caller works out the
> remaining symmetries belonging to the
> subgroup and passes these as input.
>
> Following your hint and looking at the code, this does not look
> difficult in principle.  But there are
> API design issues which I don't feel qualified to make.  And for
> maintenance reasons it would be
> best if any change was incorporated into future spglib releases.
>
> Is it realistic to request an enhancement to spglib to do this?
>
> sincerely
>
> Keith Refson
>
>
> On 27/03/14 04:44, Atsushi Togo wrote:
>> Hello,
>>
>> I'm a developer of spglib.
>>
>> 1) I think it's not a very hard work. lattice parameters are necessary
>> to be supplied for hal_get_hall_symbol, but for this purpose, just
>> dummy lattice parameters should be OK.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Spglib-users mailing list
> Spg...@li...
> https://lists.sourceforge.net/lists/listinfo/spglib-users



-- 
Atsushi Togo
Elements Strategy Initiative for Structural Materials, Kyoto university
E-mail: atz...@gm...

Re: [Spglib-users] Determine spacegroup given symmetry operations

[Atsushi T. <atz...@gm...>]

Hi Keith,

I could find my time to concentrate on working on this feature.

It's in the develop branch in github spglib repository. The tentative
function name is spg_get_hall_number_from_symmetry.
The tentative function definition is found here.
https://github.com/atztogo/spglib/blob/develop/src/spglib.h#L231
By this function, hall_number is obtained. More space group type
information is obtained by spg_get_spacegroup_type with this number.

I haven't implemented the Fortran wrapper but the python wrapper is
done. I ran some test by the following script,

https://github.com/atztogo/spglib/blob/develop/python/test/test_hall_number_from_symmetry.py

In this script, symmetry operations are searched from a crystal
structure and they are used to search space group type as Hall number
(this name t is not defined in crystallography, but a nick name used
in spglib). Then this script checks consistency between Hall number in
the symmetry search from the crystal structure and hall number from
this new function.

In my test, one crystal structure failed in the consistency check, but
all others passed. I mean I hope nomal cases are to be well handled.
The failed one is a distorted crystal structure, which is a naive case
in symmetry handling, i.e., obtained symmetry operations are
numerically distorted, too. Currently I don't have enough amount of
experience around tolerance in this new function, and I have no idea
how to make it more robust, but there would be a solution found in the
future, I hope.

Togo

On Wed, Apr 6, 2016 at 11:27 PM, Atsushi Togo <atz...@gm...> wrote:
> Hi,
>
> It's a nice feature.
>
> If the symmetry operations and lattice parameters are those for the
> primitive cell, it will be very easy (I supposed this case before). If
> not, some more implementation is necessary. But in principle, as an
> input, lattice parameters are unnecessary. I will think.
>
> Togo
>
> On Wed, Apr 6, 2016 at 6:01 PM, Keith Refson <kr...@gm...> wrote:
>> Hi,
>>
>> I'd like to pick up on a question I raised a couple of years ago, as an
>> enhancement
>> to the spglib API.
>>
>> The functionality I need is to pass a lattice and set of symmetry operations
>> as input parameters and obtain the space group - for example as an
>> SpglibDataset.
>> Specifically the atomic co-ordinates are NOT to be used to determine the
>> symmetries.
>>
>> The reason for this is for use in electronic structure codes in the
>> presence of symmetry-breaking.
>> It is commonly necessary to work in a subgroup, where the symmetry is
>> broken by, for example,
>> a magnetic structure, an anisotropic external stress or an electric
>> field or atomic displacement
>> perturbation, or a supercell where the supercell lattice vectors do not
>> transform invariantly under
>> the full point group.  The idea is that the caller works out the
>> remaining symmetries belonging to the
>> subgroup and passes these as input.
>>
>> Following your hint and looking at the code, this does not look
>> difficult in principle.  But there are
>> API design issues which I don't feel qualified to make.  And for
>> maintenance reasons it would be
>> best if any change was incorporated into future spglib releases.
>>
>> Is it realistic to request an enhancement to spglib to do this?
>>
>> sincerely
>>
>> Keith Refson
>>
>>
>> On 27/03/14 04:44, Atsushi Togo wrote:
>>> Hello,
>>>
>>> I'm a developer of spglib.
>>>
>>> 1) I think it's not a very hard work. lattice parameters are necessary
>>> to be supplied for hal_get_hall_symbol, but for this purpose, just
>>> dummy lattice parameters should be OK.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Spglib-users mailing list
>> Spg...@li...
>> https://lists.sourceforge.net/lists/listinfo/spglib-users
>
>
>
> --
> Atsushi Togo
> Elements Strategy Initiative for Structural Materials, Kyoto university
> E-mail: atz...@gm...



-- 
Atsushi Togo
Elements Strategy Initiative for Structural Materials, Kyoto university
E-mail: atz...@gm...