spglib-users — Mailing list for the spglib users

[Spglib-users] How to determine 2D plane groups using spglib code?

[Vei W. <wa...@ic...>]

Hi, I have a question about finding 2D plane groups using spglib code? Could anyone give me some advice on the matter. Thanks.

[Spglib-users] Spglib v1.12 released

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

Dear spglib users,

Spglib v1.12.0 released. ChangeLog is found here,

https://github.com/atztogo/spglib/blob/master/ChangeLog

On the surface, there is no big change. Site-symmetry symbols are
supported experimentally in spglib-dataset.

Togo

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

[Spglib-users] Spglib v1.11.2 released (bug fix)

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

Dear spglib users,

This is the release for a bug fix. Origin shift was still not
correctly computed. This bug affected to 'origin_shift' and
'std_positions', 'wyckoffs' in spglib dataset and the functions
'spg_standardize_cell', 'spg_find_primitive', and 'spg_refine_cell'.
This bug doesn't exist in v1.10.x or earlier.

Togo

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

[Spglib-users] spglib 1.11.1 released (bug fix)

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

Dear spglib users,

I found a bug in version 1.11.0 and fixed it. This bug was introduced
at version 1.11.0. Please update to version 1.11.1 if you use version
1.11.0. The detail is written in ChangeLog found here,
https://github.com/atztogo/spglib/blob/master/ChangeLog

Togo

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

[Spglib-users] spglib 1.11.0 released

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

Dear spglib users,

Spglib 1.11.0 has been released. I hope people become happy to use
spglib. Probably I didn't announce that I wrote a text of spglib
algorithm. https://arxiv.org/abs/1808.01590.

The feature to standardize (and idealize) crystal structure often
introduces user's confusion. To make it a bit more clear, I worked to
choose a bit more natural transformation_matrix than before among
possible ones by symmetry operations. In addition, a rigid rotation
introduced in the idealization step of the standardized crystal
structure is given. For these, I wrote some more documentation. By
these, users may be possible to how they work by touching values.

The rotation matrix is given in dataset as 'std_rotation_matrix'.
- https://atztogo.github.io/spglib/dataset.html#std-rotation-matrix
I think this is not so useful, but may be helpful to understand the
difference between change of basis and rotation. Some definitions and
my ideas are written be as follows:
- https://atztogo.github.io/spglib/definition.html#rotation-introduced-by-idealization
- https://atztogo.github.io/spglib/definition.html#computing-rigid-rotation-introduced-by-idealization

'mapping_to_primitive' resulted in user's confusion. So this will be
deprecated at version spglib-2.0.0.

Togo

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

Re: [Spglib-users] primitive atom consistency

[Noam B. <noa...@nr...>]

> On Oct 31, 2018, at 9:11 PM, Atsushi Togo <atz...@gm...> wrote:
> 
> Hi,
> 
> Can we move to github issue for discussion? Probably easier to discuss there.
> https://github.com/atztogo/spglib/issues/67 <https://github.com/atztogo/spglib/issues/67>

Sure.  I’ll follow up there.

								Noam


____________
||
|U.S. NAVAL|
|_RESEARCH_|
LABORATORY
Noam Bernstein, Ph.D.
Center for Materials Physics and Technology
U.S. Naval Research Laboratory
T +1 202 404 8628  F +1 202 404 7546
https://www.nrl.navy.mil <https://www.nrl.navy.mil/>

Re: [Spglib-users] primitive atom consistency

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

Hi,

Can we move to github issue for discussion? Probably easier to discuss there.
https://github.com/atztogo/spglib/issues/67

Togo
On Wed, Oct 31, 2018 at 10:31 PM Noam Bernstein
<noa...@nr...> wrote:
>
> On Oct 30, 2018, at 8:54 PM, Atsushi Togo <atz...@gm...> wrote:
>
> Currently yes, the code is written so. Do you recommend me to
> guarantee this for the future?
>
>
> Yes, I think that would be essentially required for get_symmetry_dataset()[“mapping_to_primitive”] to be meaningful.  Let me explain my use case.  Basically, I have some code that symmetrizes approximate configurations by doing get_symmetry_dataset, figuring out the transformation and rotation from the primitive cell vectors to the actual cell vectors, and then “rebuilds” a symmetrized version of the full atomic configuration by figuring out which ideal primitive cell supercell atom position corresponds to each real atom position, and moving the real atom to that position.  This always works, and produces fully symmetrized cell vectors as well as positions.
>
> To do this, I need to figure out for each actual atom position what (rotated) primitive cell supercell atom it’s closest to.  The easiest way I thought of was to find for each atom the primitive cell mapping (which is returned by get_symmetry_dataset), and calculate the difference between the real atom position and the corresponding primitive atom position (in the rotated primitive cell), transform the difference to scaled positions and round that difference (which should be nearly integers, since each atom should be close to an atom in the rotated primitive supercell up to some primitive cell vectors).  This only works if the indices returned by mapping_to_primitive are consistent with the order of atoms returned by find_primitive.  In fact, it’s basically meaningless to return mapping_to_primitive is this were not guaranteed, because you wouldn’t know which primitive atoms are mapped to.
>
> The reasons I asked this question is because I’m 95% sure that I ran into a situation where the two were not consistent with each other, and it led to a bug in my symmetrization code.  Unfortunately I forgot to save the configuration, and now I can’t reproduce it, so if there really is a bug in the consistency between get_symmetry_dataset()[“mapping_to_primitive”] and find_primitive, I can’t actually demonstrate it.  Instead, I switched my code to ignore the mapping, and send each atom to the position of the nearest atom (regardless of the mapping) in the rotated primitive supercell, which I think should always work.
>
> I couldn’t quite figure out how to do it with the quantities returned by get_symmetry_dataset() now, which are
>
> mapping_to_primitive
> std_mapping_to_primitive
> std_lattice, std_positions, std_types
>
>
> As a more general but related question, is there a reason why get_symmetry_dataset() returns those quantities?  I would have expected to get back a self-consistent set of related quantities, e.g. mapping_to_primitive and primitive_{lattice,positions,types}, or mapping_to_std and std_{lattice,positions,types}?
>
> thanks,
> Noam
>
> _______________________________________________
> 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] primitive atom consistency

[Noam B. <noa...@nr...>]

> On Oct 31, 2018, at 9:30 AM, Noam Bernstein <noa...@nr...> wrote:
> 
> The reasons I asked this question is because I’m 95% sure that I ran into a situation where the two were not consistent with each other, and it led to a bug in my symmetrization code.  Unfortunately I forgot to save the configuration, and now I can’t reproduce it, so if there really is a bug in the consistency between get_symmetry_dataset()[“mapping_to_primitive”] and find_primitive, I can’t actually demonstrate it. 


Aha - I have a demonstration.  Two cells, different only by tiny perturbations, where in one case mapping_to_primitive and the results of find_primitive are consistent, and one where they are not.  Show with
python check_primitive_mapping.py primitive_mapping_OK.xyz
and the corresponding primitive_mapping_bad.xyz.

Note that the primitive atoms scaled positions returned by find_primitive() in the two cases are different, but the mapping to primitive atoms returned by get_symmetry_dataset() is the same.

If anyone has any idea as to what’s going on, I’d be very interested in a fix.

												Noam

Re: [Spglib-users] primitive atom consistency

[Noam B. <noa...@nr...>]

> On Oct 30, 2018, at 8:54 PM, Atsushi Togo <atz...@gm...> wrote:
> 
> Currently yes, the code is written so. Do you recommend me to
> guarantee this for the future?

Yes, I think that would be essentially required for get_symmetry_dataset()[“mapping_to_primitive”] to be meaningful.  Let me explain my use case.  Basically, I have some code that symmetrizes approximate configurations by doing get_symmetry_dataset, figuring out the transformation and rotation from the primitive cell vectors to the actual cell vectors, and then “rebuilds” a symmetrized version of the full atomic configuration by figuring out which ideal primitive cell supercell atom position corresponds to each real atom position, and moving the real atom to that position.  This always works, and produces fully symmetrized cell vectors as well as positions.

To do this, I need to figure out for each actual atom position what (rotated) primitive cell supercell atom it’s closest to.  The easiest way I thought of was to find for each atom the primitive cell mapping (which is returned by get_symmetry_dataset), and calculate the difference between the real atom position and the corresponding primitive atom position (in the rotated primitive cell), transform the difference to scaled positions and round that difference (which should be nearly integers, since each atom should be close to an atom in the rotated primitive supercell up to some primitive cell vectors).  This only works if the indices returned by mapping_to_primitive are consistent with the order of atoms returned by find_primitive.  In fact, it’s basically meaningless to return mapping_to_primitive is this were not guaranteed, because you wouldn’t know which primitive atoms are mapped to.

The reasons I asked this question is because I’m 95% sure that I ran into a situation where the two were not consistent with each other, and it led to a bug in my symmetrization code.  Unfortunately I forgot to save the configuration, and now I can’t reproduce it, so if there really is a bug in the consistency between get_symmetry_dataset()[“mapping_to_primitive”] and find_primitive, I can’t actually demonstrate it.  Instead, I switched my code to ignore the mapping, and send each atom to the position of the nearest atom (regardless of the mapping) in the rotated primitive supercell, which I think should always work.  

I couldn’t quite figure out how to do it with the quantities returned by get_symmetry_dataset() now, which are
mapping_to_primitive
std_mapping_to_primitive
std_lattice, std_positions, std_types

As a more general but related question, is there a reason why get_symmetry_dataset() returns those quantities?  I would have expected to get back a self-consistent set of related quantities, e.g. mapping_to_primitive and primitive_{lattice,positions,types}, or mapping_to_std and std_{lattice,positions,types}?

												thanks,
												Noam

Re: [Spglib-users] primitive atom consistency

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

Currently yes, the code is written so. Do you recommend me to
guarantee this for the future?

Togo
On Wed, Oct 31, 2018 at 2:23 AM Noam Bernstein
<noa...@nr...> wrote:
>
> Hi - I have a question about finding the primitive cell/atoms from a supercell.  Is it supposed to be guaranteed that (with the python interface) find_primitive returns indices that are consistent with the mapping_to_primitive entry returned by get_symmetry_dataset?  I.e. if get_symmetry_dataset(at)[“mapping_to_primitive”] is 0 for an atom, does that guarantee that it matches the first entry in the items returned from find_primitive?
>
>                                                                                         Noam
>
>
>
> _______________________________________________
> 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...

[Spglib-users] primitive atom consistency

[Noam B. <noa...@nr...>]

Hi - I have a question about finding the primitive cell/atoms from a supercell.  Is it supposed to be guaranteed that (with the python interface) find_primitive returns indices that are consistent with the mapping_to_primitive entry returned by get_symmetry_dataset?  I.e. if get_symmetry_dataset(at)[“mapping_to_primitive”] is 0 for an atom, does that guarantee that it matches the first entry in the items returned from find_primitive?

											Noam

Re: [Spglib-users] dataset=None from get_symmetry_dataset()

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

I forgot to reply this to spglib mailing list.
This was fixed at
https://github.com/atztogo/spglib/commit/0106f2cca20db7eb27a0c04b7ecd5528b0ebf5b6
.

Togo
On Fri, Oct 26, 2018 at 3:53 AM Noam Bernstein
<noa...@nr...> wrote:
>
>  We’re doing some runs with perhaps slightly weird unit cells (e.g. 11 or 13 atoms), and spglib (via the python interface) occasionally seems to segmentation fault with the following stack trace:
>
> [compute-1-37:10669] *** Process received signal ***
> [compute-1-37:10669] Signal: Segmentation fault (11)
> [compute-1-37:10669] Signal code: Address not mapped (1)
> [compute-1-37:10669] Failing at address: 0x2b5093f547c0
> [compute-1-37:10669] [ 0] /lib64/libpthread.so.0[0x3011e0f7e0]
> [compute-1-37:10669] [ 1] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(ptg_get_pointgroup+0x27)[0x2b4c651f7457]
> [compute-1-37:10669] [ 2] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(ref_get_exact_structure_and_symmetry+0xf36)[0x2b4c651f9d86]
> [compute-1-37:10669] [ 3] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(det_determine_all+0x157)[0x2b4c651f0357]
> [compute-1-37:10669] [ 4] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(+0x16273)[0x2b4c651ff273]
> [compute-1-37:10669] [ 5] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(+0x4ff7)[0x2b4c651edff7]
> [compute-1-37:10669] [ 6] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5a40)[0x2b4c3fc4dc30]
> [compute-1-37:10669] [ 7] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
> [compute-1-37:10669] [ 8] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97)[0x2b4c3fc4dd87]
> [compute-1-37:10669] [ 9] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
> [compute-1-37:10669] [10] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97)[0x2b4c3fc4dd87]
> [compute-1-37:10669] [11] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
> [compute-1-37:10669] [12] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x2b4c3fc4f862]
> [compute-1-37:10669] [13] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0xb0)[0x2b4c3fc6f6d0]
> [compute-1-37:10669] [14] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0xef)[0x2b4c3fc6f8af]
> [compute-1-37:10669] [15] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(Py_Main+0xc74)[0x2b4c3fc851c4]
> [compute-1-37:10669] [16] /lib64/libc.so.6(__libc_start_main+0x100)[0x3011a1ed20]
> [compute-1-37:10669] [17] python[0x400649]
> [compute-1-37:10669] *** End of error message ***
>
>
> unfortunately there’s a random number involved and I can’t reproduce the exact run, but when I try, I do get configurations that lead to spglib.get_symmetry_dataset() returning None.  What does that mean (as opposed to group 1, which has no non-identity symmetry operations)?
>
> I’ll also try to produce a version of spglib with debugging flags on, so I can at least get a more informative stack trace when it happens again.
>
> Noam
>
> _______________________________________________
> 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...

[Spglib-users] dataset=None from get_symmetry_dataset()

[Noam B. <noa...@nr...>]

 We’re doing some runs with perhaps slightly weird unit cells (e.g. 11 or 13 atoms), and spglib (via the python interface) occasionally seems to segmentation fault with the following stack trace:
[compute-1-37:10669] *** Process received signal ***
[compute-1-37:10669] Signal: Segmentation fault (11)
[compute-1-37:10669] Signal code: Address not mapped (1)
[compute-1-37:10669] Failing at address: 0x2b5093f547c0
[compute-1-37:10669] [ 0] /lib64/libpthread.so.0[0x3011e0f7e0]
[compute-1-37:10669] [ 1] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(ptg_get_pointgroup+0x27)[0x2b4c651f7457]
[compute-1-37:10669] [ 2] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(ref_get_exact_structure_and_symmetry+0xf36)[0x2b4c651f9d86]
[compute-1-37:10669] [ 3] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(det_determine_all+0x157)[0x2b4c651f0357]
[compute-1-37:10669] [ 4] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(+0x16273)[0x2b4c651ff273]
[compute-1-37:10669] [ 5] /usr/local/python/install/python.2.7.10/lib/python2.7/site-packages/spglib/_spglib.so(+0x4ff7)[0x2b4c651edff7]
[compute-1-37:10669] [ 6] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5a40)[0x2b4c3fc4dc30]
[compute-1-37:10669] [ 7] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
[compute-1-37:10669] [ 8] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97)[0x2b4c3fc4dd87]
[compute-1-37:10669] [ 9] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
[compute-1-37:10669] [10] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b97)[0x2b4c3fc4dd87]
[compute-1-37:10669] [11] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x88e)[0x2b4c3fc4f74e]
[compute-1-37:10669] [12] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x2b4c3fc4f862]
[compute-1-37:10669] [13] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0xb0)[0x2b4c3fc6f6d0]
[compute-1-37:10669] [14] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0xef)[0x2b4c3fc6f8af]
[compute-1-37:10669] [15] /usr/local/python/install/python.2.7.10/lib/libpython2.7.so.1.0(Py_Main+0xc74)[0x2b4c3fc851c4]
[compute-1-37:10669] [16] /lib64/libc.so.6(__libc_start_main+0x100)[0x3011a1ed20]
[compute-1-37:10669] [17] python[0x400649]
[compute-1-37:10669] *** End of error message ***

unfortunately there’s a random number involved and I can’t reproduce the exact run, but when I try, I do get configurations that lead to spglib.get_symmetry_dataset() returning None.  What does that mean (as opposed to group 1, which has no non-identity symmetry operations)?  

I’ll also try to produce a version of spglib with debugging flags on, so I can at least get a more informative stack trace when it happens again.

													Noam

[Spglib-users] Actual reciprocal lattice vectors in Spglib

[Marcos V. A. <mar...@id...>]

Hi all,

We’re implementing a post-processing module in Siesta for getting a list of
k-points in the IBZ through a Monkhorst-Pack grid, so that energy levels
are obtained at these points for later use in Boltzmann transport
calculations.

We are having some trouble, however, and it would be good to have the
actual reciprocal lattice vectors that Spglib generates for a given
real-space cell, to check if they are the same that Siesta uses. Is there
any way to get these vectors as output of one of Spglib’s functions?

Best regards,

Marcos.
-- 
---

Prof. Dr. Marcos Verissimo Alves
Prof. Adjunto II, Curso de Física Computacional
Departamento de Física, Instituto de Ciências Exatas
Universidade Federal Fluminense
Volta Redonda - RJ, Brasil

[Spglib-users] Is it possible to determine 14 Bravais lattices using spglib

[Vei W. <wa...@ic...>]

Dear All,

I have a question about the determination of Bravais lattice type. Is it possible to realize by calling spglib?   

Best,
WANG

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

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

Hi,

This is a good approach, and definitely better than that I wrote. So
clearly it's not necessary to compare. SVD is in numpy, so it is easy
to do it in the case of Python.

Togo

On Thu, Dec 21, 2017 at 12:26 AM, Noam Bernstein
<noa...@nr...> wrote:
> On Dec 19, 2017, at 10:01 PM, Atsushi Togo <atz...@gm...> wrote:
>
> Hi,
>
> Thanks for making your script simple.
> I see the documentation is confusing. dataset['std_lattice'] includes
> rotation, but the transformation matrix doesn't rotate.
>
> I answer to your questions 1 and 2. 1 yes. 2, the mathematical
> expression must contain rotation matrix.
>
> I wrote a script to do this job.
>
>
> Thank you very much for the clarification, and the very helpful code.  I’ve
> been using SVD to find the best fit rotation (as per
> https://igl.ethz.ch/projects/ARAP/svd_rot.pdf Eq. 17 and 21), but I’ll look
> at your example and see how the results of that method and yours differ.
>
> Noam
>
> ____________
> |
> |
> |
> U.S. NAVAL
> |
> |
> _RESEARCH_
> |
> LABORATORY
>
> Noam Bernstein, Ph.D.
> Center for Materials Physics and Technology
> U.S. Naval Research Laboratory
> T +1 202 404 8628  F +1 202 404 7546
> https://www.nrl.navy.mil
>



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

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

[Noam B. <noa...@nr...>]

> On Dec 19, 2017, at 10:01 PM, Atsushi Togo <atz...@gm...> wrote:
> 
> Hi,
> 
> Thanks for making your script simple.
> I see the documentation is confusing. dataset['std_lattice'] includes
> rotation, but the transformation matrix doesn't rotate.
> 
> I answer to your questions 1 and 2. 1 yes. 2, the mathematical
> expression must contain rotation matrix.
> 
> I wrote a script to do this job.

Thank you very much for the clarification, and the very helpful code.  I’ve been using SVD to find the best fit rotation (as per https://igl.ethz.ch/projects/ARAP/svd_rot.pdf Eq. 17 and 21), but I’ll look at your example and see how the results of that method and yours differ.

										Noam


____________
||
|U.S. NAVAL|
|_RESEARCH_|
LABORATORY
Noam Bernstein, Ph.D.
Center for Materials Physics and Technology
U.S. Naval Research Laboratory
T +1 202 404 8628  F +1 202 404 7546
https://www.nrl.navy.mil <https://www.nrl.navy.mil/>

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

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

Hi,

Thanks for making your script simple.
I see the documentation is confusing. dataset['std_lattice'] includes
rotation, but the transformation matrix doesn't rotate.

I answer to your questions 1 and 2. 1 yes. 2, the mathematical
expression must contain rotation matrix.

I wrote a script to do this job.

import spglib
import numpy as np

# Original basis vectors in row vectors
orig_basis = np.array([[0,1.41421356237309504880,0],
                       [.70710678118654752440,.70710678118654752440,1],
                       [-.70710678118654752440,.70710678118654752440,1]]).T
positions = [[0,0,0]]
atomic_numbers = [32]

cell = (orig_basis.T, positions, atomic_numbers)
dataset = spglib.get_symmetry_dataset(cell, symprec=0.1)
space_group_type = dataset['international']
centring = space_group_type[0]
t_mat = dataset['transformation_matrix']
F_centre_t_mat = np.array([[0, 1, 1],
                           [1, 0, 1],
                           [1, 1, 0]]) * 0.5 # P_F in spglib doc
rotated_std_basis = dataset['std_lattice'].T # in row vectors
std_basis = np.dot(orig_basis, np.linalg.inv(t_mat)) # in row_vectors
R = np.dot(rotated_std_basis, np.linalg.inv(std_basis)) # rotation matrix

print("space group type %s: %s-centring" % (space_group_type, centring))
print("orig basis (row vectors)\n", orig_basis)
print("transformation  matrix\n", t_mat)
print("standardized basis (row vectors)\n", std_basis)
print("standardized basis with rotation in Cartesian coordinates "
      "(row vectors)\n", rotated_std_basis)
print("Rotation matrix (R)\n", R)
print("det(R) = %f" % np.linalg.det(R))

# Tranformation back
# Rotation matrix has to be a rigit rotation matrix.
# For example, I used Euler angles to polish the above rotation matrix.
# I didn't examine carefully if my code is general or not.
# I installed http://matthew-brett.github.io/transforms3d/
from transforms3d.euler import mat2euler, euler2mat
R_new = euler2mat(*mat2euler(R))

recovered_std_basis = np.dot(np.linalg.inv(R_new), rotated_std_basis)
# Transformation matrix may be distorted.
# So an additional treatment is applied.
recovered_std_prim_basis = np.dot(recovered_std_basis, F_centre_t_mat)
t_mat_to_orig_basis_from_prim_basis = np.dot(
    np.linalg.inv(recovered_std_prim_basis), orig_basis)
# The matrix elements of this matrix have to be integers, so let's cast to int
t_mat_int = np.rint(t_mat_to_orig_basis_from_prim_basis).astype(int)
assert abs(abs(np.linalg.det(t_mat_int)) - 1) < 1e-10

final_basis = np.dot(recovered_std_prim_basis, t_mat_int)
print("final basis (row vectors)\n", final_basis)


The output is as follows:

space group type Fm-3m: F-centring
orig basis (row vectors)
 [[ 0.          0.70710678 -0.70710678]
 [ 1.41421356  0.70710678  0.70710678]
 [ 0.          1.          1.        ]]
transformation  matrix
 [[  0.00000000e+00  -5.00000000e-01  -5.00000000e-01]
 [  5.00000000e-01   5.00000000e-01  -7.51373070e-17]
 [ -5.00000000e-01   1.96261557e-17  -5.00000000e-01]]
standardized basis (row vectors)
 [[  0.00000000e+00   1.41421356e+00   1.41421356e+00]
 [ -2.22044605e-16   1.41421356e+00  -1.41421356e+00]
 [ -2.00000000e+00   0.00000000e+00   0.00000000e+00]]
standardized basis with rotation in Cartesian coordinates (row vectors)
 [[ 2.  0.  0.]
 [ 0.  2.  0.]
 [ 0.  0.  2.]]
Rotation matrix (R)
 [[  0.00000000e+00   0.00000000e+00  -1.00000000e+00]
 [  7.07106781e-01   7.07106781e-01  -7.85046229e-17]
 [  7.07106781e-01  -7.07106781e-01   7.85046229e-17]]
det(R) = 1.000000
final basis (row vectors)
[[  3.33066907e-16   7.07106781e-01  -7.07106781e-01]
[  1.41421356e+00   7.07106781e-01   7.07106781e-01]
[  0.00000000e+00   1.00000000e+00   1.00000000e+00]]


Togo

On Tue, Dec 19, 2017 at 10:49 PM, Noam Bernstein
<noa...@nr...> wrote:
> On Dec 18, 2017, at 7:02 PM, Atsushi Togo <atz...@gm...> wrote:
>
> Your sample script is busy, and I want to see only essential
> information. In addition I don't have ASE in my computer.
>
>
> Sorry - I tried to make sure it was printing everything that I thought was
> helpful to understand the behavior, but here’s a version with the extra
> print statements removed and without ASE:
>
> import spglib, numpy as np
> orig_cell=np.array([[0,1.41421356237309504880,0],
>                     [.70710678118654752440,.70710678118654752440,1],
>                     [-.70710678118654752440,.70710678118654752440,1]])
> positions=[[0,0,0]]
> atomic_numbers=[32]
>
> dataset = spglib.get_symmetry_dataset((orig_cell, positions,
> atomic_numbers), symprec=0.1)
> print "orig cell\n", orig_cell
> print "supposed to be orig cell\n", np.dot(dataset['std_lattice'].T,
> dataset['transformation_matrix']).T
>
>  output:
>
> orig cell
> [[ 0.          1.41421356  0.        ]
>  [ 0.70710678  0.70710678  1.        ]
>  [-0.70710678  0.70710678  1.        ]]
> supposed to be orig cell
> [[  0.00000000e+00   1.00000000e+00  -1.00000000e+00]
>  [ -1.00000000e+00   1.00000000e+00   3.92523115e-17]
>  [ -1.00000000e+00  -1.50274614e-16  -1.00000000e+00]]
>
> Obviously, the original cell and what I expected would be the same as the
> original cell are not in fact the same, so clearly I’m misunderstanding
> something.
>
>
> By the way, do you understand the difference between transformation
> and rotation? The former is a change of basis and the later is rigid
> rotation of whole crystal in Cartesian coordinates. The former is
> applied from the right and the later is applied from the left if I am
> correct.
>
>
> Thanks for the clarification.  I’m just trying to understand why the
> documentation (at
> https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation)
> says
>
> (a b c) = (a_s b_s c_s) P
>
> where a, b, and c are the original cell vectors, a_s, b_s, and c_s are the
> standardized cell vectors returned by get_symmetry_dataset, and P is the
> transformation matrix returned by get_symmetry_dataset.  However, when I try
> to do that multiplication by transforming the cell 3x3 matrices which have
> each lattice vector as a row into column vectors (which is my understanding
> of the expression in the docs), and right multiplying by the transformation
> matrix, the equality is not satisfied.
>
> 1. Do you agree that it should be possible to get two identical 3x3 matrices
> (assuming the initial symmetry is in fact perfect), one of which is the
> original cell vectors and the other is a product of some simple functions
> (e.g. transpose and/or inverse) of dataset[‘std_lattice’] and
> dataset[‘transformation matrix’]?
> 2. Do you agree that what my code above implements is indeed the
> mathematical expression from the documentation?  If not, what is the correct
> operation?
>
>
> thanks,
> Noam



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

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

[Noam B. <noa...@nr...>]

> On Dec 18, 2017, at 7:02 PM, Atsushi Togo <atz...@gm...> wrote:
> 
> Your sample script is busy, and I want to see only essential
> information. In addition I don't have ASE in my computer.

Sorry - I tried to make sure it was printing everything that I thought was helpful to understand the behavior, but here’s a version with the extra print statements removed and without ASE:
import spglib, numpy as np
orig_cell=np.array([[0,1.41421356237309504880,0],
                    [.70710678118654752440,.70710678118654752440,1],
                    [-.70710678118654752440,.70710678118654752440,1]])
positions=[[0,0,0]]
atomic_numbers=[32]

dataset = spglib.get_symmetry_dataset((orig_cell, positions, atomic_numbers), symprec=0.1)
print "orig cell\n", orig_cell
print "supposed to be orig cell\n", np.dot(dataset['std_lattice'].T, dataset['transformation_matrix']).T
 output:
orig cell
[[ 0.          1.41421356  0.        ]
 [ 0.70710678  0.70710678  1.        ]
 [-0.70710678  0.70710678  1.        ]]
supposed to be orig cell
[[  0.00000000e+00   1.00000000e+00  -1.00000000e+00]
 [ -1.00000000e+00   1.00000000e+00   3.92523115e-17]
 [ -1.00000000e+00  -1.50274614e-16  -1.00000000e+00]]
Obviously, the original cell and what I expected would be the same as the original cell are not in fact the same, so clearly I’m misunderstanding something.

> 
> By the way, do you understand the difference between transformation
> and rotation? The former is a change of basis and the later is rigid
> rotation of whole crystal in Cartesian coordinates. The former is
> applied from the right and the later is applied from the left if I am
> correct.

Thanks for the clarification.  I’m just trying to understand why the documentation (at https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation <https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation>) says 
(a b c) = (a_s b_s c_s) P
where a, b, and c are the original cell vectors, a_s, b_s, and c_s are the standardized cell vectors returned by get_symmetry_dataset, and P is the transformation matrix returned by get_symmetry_dataset.  However, when I try to do that multiplication by transforming the cell 3x3 matrices which have each lattice vector as a row into column vectors (which is my understanding of the expression in the docs), and right multiplying by the transformation matrix, the equality is not satisfied.

1. Do you agree that it should be possible to get two identical 3x3 matrices (assuming the initial symmetry is in fact perfect), one of which is the original cell vectors and the other is a product of some simple functions (e.g. transpose and/or inverse) of dataset[‘std_lattice’] and dataset[‘transformation matrix’]?
2. Do you agree that what my code above implements is indeed the mathematical expression from the documentation?  If not, what is the correct operation?


											thanks,
											Noam

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

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

Your sample script is busy, and I want to see only essential
information. In addition I don't have ASE in my computer.

By the way, do you understand the difference between transformation
and rotation? The former is a change of basis and the later is rigid
rotation of whole crystal in Cartesian coordinates. The former is
applied from the right and the later is applied from the left if I am
correct.

Togo

On Tue, Dec 19, 2017 at 1:18 AM, Noam Bernstein
<noa...@nr...> wrote:
>
> On Dec 16, 2017, at 2:08 AM, Atsushi Togo <atz...@gm...> wrote:
>
> You can obtain more information by spg_get_dataset:
> https://atztogo.github.io/spglib/api.html#spg-get-dataset-and-spg-get-dataset-with-hall-number
>
>
> Thanks - I now see transformation matrix, which is very helpful.  I’m
> slightly confused by the output I get, however.
>
> I tried a simple example, identifying a rotated FCC lattice.  Lattice
> vectors start out as (1,1,0) etc, and are rotate by 45 deg around \hat{z}.
>
> import ase, ase.io, sys, spglib, numpy as np
>
> at = ase.Atoms(cell=[[0,1.41421356237309504880,0],
>      [.70710678118654752440,.70710678118654752440,1],
>      [-.70710678118654752440,.70710678118654752440,1]], numbers=[32])
> ase.io.write(sys.stdout, at, format="extxyz")
>
> symprec=0.1
> dataset = spglib.get_symmetry_dataset((at.get_cell(), at.get_positions(),
> at.get_atomic_numbers()), symprec=symprec)
> sys.stderr.write("loose initial symmetry group number {}, international
> (Hermann-Mauguin) {} Hall {} prec
> {}\n".format(dataset["number"],dataset["international"],dataset["hall"],symprec))
> print "std lattice\n", dataset['std_lattice']
> print "orig cell\n", at.get_cell()
> print "supposed to be orig cell\n", np.dot(dataset['std_lattice'].T,
> dataset['transformation_matrix']).T
> print "supposed to be standardized cell\n", np.dot(at.get_cell().T,
> np.linalg.inv(dataset['transformation_matrix'])).T
>
>
> I expected the second to last line to print out something identical to the
> original cell, according to the documentation at
> https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation
> which says that "(a b c) = (as bs cs) P” (I’m using 1.9.9).  However, the
> output is actually
>
> 1
> Lattice="0.0 1.41421356237 0.0 0.707106781187 0.707106781187 1.0
> -0.707106781187 0.707106781187 1.0" Properties=species:S:1:pos:R:3:Z:I:1
> pbc="F F F"
> Ge       0.00000000       0.00000000       0.00000000       32
> loose initial symmetry group number 225, international (Hermann-Mauguin)
> Fm-3m Hall -F 4 2 3 prec 0.1
> std lattice
> [[ 2.  0.  0.]
>  [ 0.  2.  0.]
>  [ 0.  0.  2.]]
> orig cell
> [[ 0.          1.41421356  0.        ]
>  [ 0.70710678  0.70710678  1.        ]
>  [-0.70710678  0.70710678  1.        ]]
> supposed to be orig cell
> [[  0.00000000e+00   1.00000000e+00  -1.00000000e+00]
>  [ -1.00000000e+00   1.00000000e+00   3.92523115e-17]
>  [ -1.00000000e+00  -1.50274614e-16  -1.00000000e+00]]
> supposed to be standardized cell
> [[  0.00000000e+00  -2.22044605e-16  -2.00000000e+00]
>  [  1.41421356e+00   1.41421356e+00   0.00000000e+00]
>  [  1.41421356e+00  -1.41421356e+00   0.00000000e+00]]
>
> so the “supposed to be orig cell” line prints out something that is a
> _rotated_ version of the original cell.  That’s actually fine in practice,
> but it’s not what I was expecting.  Am I just misunderstanding the
> documentation, or am I actually doing something wrong?
>
> thanks,
> Noam



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

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

[Noam B. <noa...@nr...>]

> On Dec 16, 2017, at 2:08 AM, Atsushi Togo <atz...@gm...> wrote:
> 
> You can obtain more information by spg_get_dataset:
> https://atztogo.github.io/spglib/api.html#spg-get-dataset-and-spg-get-dataset-with-hall-number
> 

Thanks - I now see transformation matrix, which is very helpful.  I’m slightly confused by the output I get, however.  

I tried a simple example, identifying a rotated FCC lattice.  Lattice vectors start out as (1,1,0) etc, and are rotate by 45 deg around \hat{z}.
import ase, ase.io, sys, spglib, numpy as np

at = ase.Atoms(cell=[[0,1.41421356237309504880,0],
     [.70710678118654752440,.70710678118654752440,1],
     [-.70710678118654752440,.70710678118654752440,1]], numbers=[32])
ase.io.write(sys.stdout, at, format="extxyz")

symprec=0.1
dataset = spglib.get_symmetry_dataset((at.get_cell(), at.get_positions(), at.get_atomic_numbers()), symprec=symprec)
sys.stderr.write("loose initial symmetry group number {}, international (Hermann-Mauguin) {} Hall {} prec {}\n".format(dataset["number"],dataset["international"],dataset["hall"],symprec))
print "std lattice\n", dataset['std_lattice']
print "orig cell\n", at.get_cell()
print "supposed to be orig cell\n", np.dot(dataset['std_lattice'].T, dataset['transformation_matrix']).T
print "supposed to be standardized cell\n", np.dot(at.get_cell().T, np.linalg.inv(dataset['transformation_matrix'])).T

I expected the second to last line to print out something identical to the original cell, according to the documentation at
	https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation <https://atztogo.github.io/spglib/api.html#api-origin-shift-and-transformation>
which says that "(a b c) = (as bs cs) P” (I’m using 1.9.9).  However, the output is actually
1
Lattice="0.0 1.41421356237 0.0 0.707106781187 0.707106781187 1.0 -0.707106781187 0.707106781187 1.0" Properties=species:S:1:pos:R:3:Z:I:1 pbc="F F F"
Ge       0.00000000       0.00000000       0.00000000       32
loose initial symmetry group number 225, international (Hermann-Mauguin) Fm-3m Hall -F 4 2 3 prec 0.1
std lattice
[[ 2.  0.  0.]
 [ 0.  2.  0.]
 [ 0.  0.  2.]]
orig cell
[[ 0.          1.41421356  0.        ]
 [ 0.70710678  0.70710678  1.        ]
 [-0.70710678  0.70710678  1.        ]]
supposed to be orig cell
[[  0.00000000e+00   1.00000000e+00  -1.00000000e+00]
 [ -1.00000000e+00   1.00000000e+00   3.92523115e-17]
 [ -1.00000000e+00  -1.50274614e-16  -1.00000000e+00]]
supposed to be standardized cell
[[  0.00000000e+00  -2.22044605e-16  -2.00000000e+00]
 [  1.41421356e+00   1.41421356e+00   0.00000000e+00]
 [  1.41421356e+00  -1.41421356e+00   0.00000000e+00]]
so the “supposed to be orig cell” line prints out something that is a _rotated_ version of the original cell.  That’s actually fine in practice, but it’s not what I was expecting.  Am I just misunderstanding the documentation, or am I actually doing something wrong?

								thanks,
								Noam

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

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

You can obtain more information by spg_get_dataset:
https://atztogo.github.io/spglib/api.html#spg-get-dataset-and-spg-get-dataset-with-hall-number

Togo

On Sat, Dec 16, 2017 at 3:04 AM, Noam Bernstein
<noa...@nr...> wrote:
>> On Dec 14, 2017, at 7:31 PM, Atsushi Togo <atz...@gm...> wrote:
>>
>> No.
>>
>> Cell vectors follow the crystallographic point group (multiplied with
>> translation group). But if I remember correctly, simple application of
>> these symmetry operations similarly to the points of atoms didn't work
>> well. So my strategy is that using the constraints of Bravais lattice
>> for angles and equivalent basis vector lengths to symmetrize the basis
>> vectors. For distorted basis vectors, it's not uniquely defined the
>> directions of basis vectors in Cartesian coordinates, I employed a
>> strategy to align those basis vectors to the Cartesian axes as shown
>> in the spglib documentation. If you want to rotate basis vectors to be
>> along some directions, you can do rotate back afterwards using the
>> rotation matrix calculated from the initial and final basis vectors
>> and the transformation matrix given from spglib. In summary, to
>> symmetrize basis vectors, there is large freedom to make it, and it
>> can be dependent on users' will, so I don't want to provide a function
>> that does too much.
>
> That sounds reasonable, except that I can’t figure out how to decompose
> the transformation from my original vectors to the symmetrized vectors into
> a supercell+deformation part and a rotation.  standardize_cell just returns
> a set of final lattice vectors. Is that separation already someplace in the code,
> or do I need to decompose the transformation matrix myself somehow?
>
>                                                                 Noam



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

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

[Noam B. <noa...@nr...>]

> On Dec 14, 2017, at 7:31 PM, Atsushi Togo <atz...@gm...> wrote:
> 
> No.
> 
> Cell vectors follow the crystallographic point group (multiplied with
> translation group). But if I remember correctly, simple application of
> these symmetry operations similarly to the points of atoms didn't work
> well. So my strategy is that using the constraints of Bravais lattice
> for angles and equivalent basis vector lengths to symmetrize the basis
> vectors. For distorted basis vectors, it's not uniquely defined the
> directions of basis vectors in Cartesian coordinates, I employed a
> strategy to align those basis vectors to the Cartesian axes as shown
> in the spglib documentation. If you want to rotate basis vectors to be
> along some directions, you can do rotate back afterwards using the
> rotation matrix calculated from the initial and final basis vectors
> and the transformation matrix given from spglib. In summary, to
> symmetrize basis vectors, there is large freedom to make it, and it
> can be dependent on users' will, so I don't want to provide a function
> that does too much.

That sounds reasonable, except that I can’t figure out how to decompose
the transformation from my original vectors to the symmetrized vectors into
a supercell+deformation part and a rotation.  standardize_cell just returns
a set of final lattice vectors. Is that separation already someplace in the code, 
or do I need to decompose the transformation matrix myself somehow?  

								Noam

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

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

No.

Cell vectors follow the crystallographic point group (multiplied with
translation group). But if I remember correctly, simple application of
these symmetry operations similarly to the points of atoms didn't work
well. So my strategy is that using the constraints of Bravais lattice
for angles and equivalent basis vector lengths to symmetrize the basis
vectors. For distorted basis vectors, it's not uniquely defined the
directions of basis vectors in Cartesian coordinates, I employed a
strategy to align those basis vectors to the Cartesian axes as shown
in the spglib documentation. If you want to rotate basis vectors to be
along some directions, you can do rotate back afterwards using the
rotation matrix calculated from the initial and final basis vectors
and the transformation matrix given from spglib. In summary, to
symmetrize basis vectors, there is large freedom to make it, and it
can be dependent on users' will, so I don't want to provide a function
that does too much.

Togo

On Fri, Dec 15, 2017 at 5:15 AM, Noam Bernstein
<noa...@nr...> wrote:
> On Sep 25, 2017, at 9:54 AM, Atsushi Togo <atz...@gm...> wrote:
>
> Good!
>
>
> Togo
>
> On Mon, Sep 25, 2017 at 10:49 PM, Noam Bernstein
> <noa...@nr...> wrote:
>
> On Sep 25, 2017, at 9:15 AM, Atsushi Togo <atz...@gm...> wrote:
>
> If the distortion is not that much, then the approach by
> Grosse-Kunstleve and Adams should work. If you write a python script,
> I think I can comment to it. The C-code is about here,
> https://github.com/atztogo/spglib/blob/master/src/site_symmetry.c#L244
>
>
>
> Hmm.  I tried something like this initially, and it wasn't working at all,
> but I must have had a bug, since I redid it cleanly (so I could show the
> code), and the new version's apparently working.  Maybe because I was coding
> for an audience I was more careful.  In any case, while I think it would be
> useful to have a version of standardize_cell() that only moved atoms,
> without touching the cell vectors, I think my problem is solved for now
> (especially if I can recode it without a tight loop in python).  It should
> probably be redone without so many tight loops in explicit python, but here
> it is, in case it’s useful for anyone else:
>
>
>
> Hi Togo - hopefully you remember this discussion.  Thanks to your help, I
> was able to code up in pure python the symmetrization of the atomic
> positions, based on your C code in site_symmetry.c.   Now I’m wondering if
> there is an equivalent algorithm for the symmetrized cell vectors.  Can you
> just apply the same algorithm to fake atoms placed at the cell vector
> endpoints?
>
> thanks,
> Noam
>
> ____________
> |
> |
> |
> U.S. NAVAL
> |
> |
> _RESEARCH_
> |
> LABORATORY
>
> Noam Bernstein, Ph.D.
> Center for Materials Physics and Technology
> U.S. Naval Research Laboratory
> T +1 202 404 8628  F +1 202 404 7546
> https://www.nrl.navy.mil
>



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

Re: [Spglib-users] symmetrizing positions/cell vectors without altering cell?

[Noam B. <noa...@nr...>]

> On Sep 25, 2017, at 9:54 AM, Atsushi Togo <atz...@gm...> wrote:
> 
> Good!

> 
> Togo
> 
> On Mon, Sep 25, 2017 at 10:49 PM, Noam Bernstein
> <noa...@nr...> wrote:
>> On Sep 25, 2017, at 9:15 AM, Atsushi Togo <atz...@gm...> wrote:
>> 
>> If the distortion is not that much, then the approach by
>> Grosse-Kunstleve and Adams should work. If you write a python script,
>> I think I can comment to it. The C-code is about here,
>> https://github.com/atztogo/spglib/blob/master/src/site_symmetry.c#L244
>> 
>> 
>> 
>> Hmm.  I tried something like this initially, and it wasn't working at all,
>> but I must have had a bug, since I redid it cleanly (so I could show the
>> code), and the new version's apparently working.  Maybe because I was coding
>> for an audience I was more careful.  In any case, while I think it would be
>> useful to have a version of standardize_cell() that only moved atoms,
>> without touching the cell vectors, I think my problem is solved for now
>> (especially if I can recode it without a tight loop in python).  It should
>> probably be redone without so many tight loops in explicit python, but here
>> it is, in case it’s useful for anyone else:



Hi Togo - hopefully you remember this discussion.  Thanks to your help, I was able to code up in pure python the symmetrization of the atomic positions, based on your C code in site_symmetry.c.   Now I’m wondering if there is an equivalent algorithm for the symmetrized cell vectors.  Can you just apply the same algorithm to fake atoms placed at the cell vector endpoints?

									thanks,
									Noam


____________
||
|U.S. NAVAL|
|_RESEARCH_|
LABORATORY
Noam Bernstein, Ph.D.
Center for Materials Physics and Technology
U.S. Naval Research Laboratory
T +1 202 404 8628  F +1 202 404 7546
https://www.nrl.navy.mil <https://www.nrl.navy.mil/>