Port spglib to Avogadro2

Development
1

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[][3][3],
double origin_shift[][3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

2

Hi,

If you mean origin_shift as non primitive translation part of space
group operations, I can understand what you wrote. I can extend spglib
so that the database is accessed from the API. The other option is
just to hard code the database in Avogadro’s crystallography extension
itself. It may be a matter of strategy. If Avogadro may have a chance
to use other crystal symmetry libraries in the future, it may be
better the later option.

Togo

On Thu, Aug 21, 2014 at 6:06 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[3][3],
double origin_shift[3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

3

On Wednesday 20 of August 2014 21:06:56 Defusco III, Albert A wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space
group support into Avogadro 2. What is missing from Avogadro 2 is a look-up
of rotation matrices and origin shift vectors for a given space group. Do
you believe it is possible to extend Sgplib so that I can get these
quantities when specifying just the space group (either Hall symbol/number
or international symbol/number)?

This data is available in OpenBabel, which Avogadro already uses. Although the
bug I posted against its database is not yet marked closed…

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in
    Avogado2’s UnitCell class and added a fillUnitCell method to
    crystaltools.cpp. A filled unit cell can then be given the the Spglib
    routines for further action. (The rotation matrices and origin shift
    vectors are only available if read from a cml file where they have been
    specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are
    nearly unchanged when ported into Avogadro2.

OK, I’m quite oblivious to how Avogadro2 works. I thought the files are loaded
using OpenBabel. That’s how Avogadro1 works. In that case, the unit cell data
is read by OpenBabel and is available in other formats besides cml (I use
CIF). This is then used in Avogadro’s
CrystallographyExtension::fillUnitCell(). Is there a reason to do it
differently in Avogadro2?

Regards
Jure

4

Can you e-mail me the space-groups.txt revision. For various reasons, I’m having whitespace issues when copying from the bug tracker. Thanks.

OK, I’m quite oblivious to how Avogadro2 works. I thought the files are loaded
using OpenBabel.

For a variety of reasons, Avogadro2 uses Open Babel as a process, rather than directly in C++. So reading files is at one step removed:

  • Open Babel reads CIF (or whatever) and writes CML
  • Avogadro opens CML directly

The main problem is that Open Babel wasn’t really designed for interactive editing of molecules where the types, hybridization are rapidly changing. There’s a bunch of code in Avogadro v1 that basically reset the perceived types with every edit. That led to some tricky threading/mutex issues where multiple parts of Avogadro want to change the molecule at the same time.

As far as crystals, Avogadro v1 also had a lot of duplicated code. Some things were done in Open Babel and some in Avogadro and some in both places (e.g., wrapping fractional coordinates into the unit cell). Now there’s a bit clearer division of work.

-Geoff

5

Hi Togo,

Yes, I meant non-primitive translation. For now I would prefer to retrieve this information from Spglib to avoid replication errors. I can have Avogadro translate a Hall symbol to the Hall number used in spg_database.c.

Dealing with International symbols and non-primitive unit cells could be troublesome, but I could always just force the user to choose an origin.

Thanks,
Albert

On Aug 20, 2014, at 7:57 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

If you mean origin_shift as non primitive translation part of space
group operations, I can understand what you wrote. I can extend spglib
so that the database is accessed from the API. The other option is
just to hard code the database in Avogadro’s crystallography extension
itself. It may be a matter of strategy. If Avogadro may have a chance
to use other crystal symmetry libraries in the future, it may be
better the later option.

Togo

On Thu, Aug 21, 2014 at 6:06 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[3][3],
double origin_shift[3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

6

Hi,

In spglib, I implemented a function to access symmetry operations of
‘conventional’ unit cell using the index of hall symbol. It’s up to
the Avogadro development strategy if Avogadro uses this function or
not. Avogadro may wait for the fix in openbabel.

The code is found at

https://github.com/atztogo/spglib/releases/tag/v1.6.2

The function is as follows:

/* Space-group operations in built-in database are accessed by index /
/ of hall symbol. The index is defined as number from 1 to 530. /
/ The muximum number of symmetry operations is 192. */
int spg_get_symmetry_from_database(int rotations[192][3][3],
double translations[192][3],
const int hall_number);

I think there is no definition of index number of hall symbol. So the
hall_number used in spglib is considered as just a local definition.
If you prepare (graphical) user interface, the hall_number should be
generated from a space group type with its setting of axes and origin.

Togo

On Fri, Aug 22, 2014 at 12:53 AM, Defusco III, Albert A
defusco@pitt.edu wrote:

Hi Togo,

Yes, I meant non-primitive translation. For now I would prefer to retrieve this information from Spglib to avoid replication errors. I can have Avogadro translate a Hall symbol to the Hall number used in spg_database.c.

Dealing with International symbols and non-primitive unit cells could be troublesome, but I could always just force the user to choose an origin.

Thanks,
Albert

On Aug 20, 2014, at 7:57 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

If you mean origin_shift as non primitive translation part of space
group operations, I can understand what you wrote. I can extend spglib
so that the database is accessed from the API. The other option is
just to hard code the database in Avogadro’s crystallography extension
itself. It may be a matter of strategy. If Avogadro may have a chance
to use other crystal symmetry libraries in the future, it may be
better the later option.

Togo

On Thu, Aug 21, 2014 at 6:06 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[3][3],
double origin_shift[3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

7

Togo,

That works perfectly. I’ll keep you informed of my progress. Would it be appropriate to set a default axis and origin for each space group if the user is uncertain of which to chose?

Thanks,
Albert

On Aug 22, 2014, at 7:56 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

In spglib, I implemented a function to access symmetry operations of
‘conventional’ unit cell using the index of hall symbol. It’s up to
the Avogadro development strategy if Avogadro uses this function or
not. Avogadro may wait for the fix in openbabel.

The code is found at

https://github.com/atztogo/spglib/releases/tag/v1.6.2

The function is as follows:

/* Space-group operations in built-in database are accessed by index /
/ of hall symbol. The index is defined as number from 1 to 530. /
/ The muximum number of symmetry operations is 192. */
int spg_get_symmetry_from_database(int rotations[192][3][3],
double translations[192][3],
const int hall_number);

I think there is no definition of index number of hall symbol. So the
hall_number used in spglib is considered as just a local definition.
If you prepare (graphical) user interface, the hall_number should be
generated from a space group type with its setting of axes and origin.

Togo

On Fri, Aug 22, 2014 at 12:53 AM, Defusco III, Albert A
defusco@pitt.edu wrote:

Hi Togo,

Yes, I meant non-primitive translation. For now I would prefer to retrieve this information from Spglib to avoid replication errors. I can have Avogadro translate a Hall symbol to the Hall number used in spg_database.c.

Dealing with International symbols and non-primitive unit cells could be troublesome, but I could always just force the user to choose an origin.

Thanks,
Albert

On Aug 20, 2014, at 7:57 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

If you mean origin_shift as non primitive translation part of space
group operations, I can understand what you wrote. I can extend spglib
so that the database is accessed from the API. The other option is
just to hard code the database in Avogadro’s crystallography extension
itself. It may be a matter of strategy. If Avogadro may have a chance
to use other crystal symmetry libraries in the future, it may be
better the later option.

Togo

On Thu, Aug 21, 2014 at 6:06 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[3][3],
double origin_shift[3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

8

Hi Albert,

I don’t check carefully, but I think the first one in the list of hall
symbols for a space group type (among 230) is the standard one.

Togo

On Mon, Aug 25, 2014 at 10:44 PM, Defusco III, Albert A
defusco@pitt.edu wrote:

Togo,

That works perfectly. I’ll keep you informed of my progress. Would it be appropriate to set a default axis and origin for each space group if the user is uncertain of which to chose?

Thanks,
Albert

On Aug 22, 2014, at 7:56 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

In spglib, I implemented a function to access symmetry operations of
‘conventional’ unit cell using the index of hall symbol. It’s up to
the Avogadro development strategy if Avogadro uses this function or
not. Avogadro may wait for the fix in openbabel.

The code is found at

https://github.com/atztogo/spglib/releases/tag/v1.6.2

The function is as follows:

/* Space-group operations in built-in database are accessed by index /
/ of hall symbol. The index is defined as number from 1 to 530. /
/ The muximum number of symmetry operations is 192. */
int spg_get_symmetry_from_database(int rotations[192][3][3],
double translations[192][3],
const int hall_number);

I think there is no definition of index number of hall symbol. So the
hall_number used in spglib is considered as just a local definition.
If you prepare (graphical) user interface, the hall_number should be
generated from a space group type with its setting of axes and origin.

Togo

On Fri, Aug 22, 2014 at 12:53 AM, Defusco III, Albert A
defusco@pitt.edu wrote:

Hi Togo,

Yes, I meant non-primitive translation. For now I would prefer to retrieve this information from Spglib to avoid replication errors. I can have Avogadro translate a Hall symbol to the Hall number used in spg_database.c.

Dealing with International symbols and non-primitive unit cells could be troublesome, but I could always just force the user to choose an origin.

Thanks,
Albert

On Aug 20, 2014, at 7:57 PM, Atsushi Togo atz.togo@gmail.com wrote:

Hi,

If you mean origin_shift as non primitive translation part of space
group operations, I can understand what you wrote. I can extend spglib
so that the database is accessed from the API. The other option is
just to hard code the database in Avogadro’s crystallography extension
itself. It may be a matter of strategy. If Avogadro may have a chance
to use other crystal symmetry libraries in the future, it may be
better the later option.

Togo

On Thu, Aug 21, 2014 at 6:06 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good afternoon everyone,

I am working on getting porting the crystallography extension and space group support into Avogadro 2. What is missing from Avogadro 2 is a look-up of rotation matrices and origin shift vectors for a given space group. Do you believe it is possible to extend Sgplib so that I can get these quantities when specifying just the space group (either Hall symbol/number or international symbol/number)?

Here’s what I’ve done so far

  1. I have added support for rotation matrices and origin shift vectors in Avogado2’s UnitCell class and added a fillUnitCell method to crystaltools.cpp. A filled unit cell can then be given the the Spglib routines for further action. (The rotation matrices and origin shift vectors are only available if read from a cml file where they have been specified in child nodes of .)

  2. Once a filled unit cell is generated all AvoSpglib/Spglib routines are nearly unchanged when ported into Avogadro2.

Here’s an example of what I mean.

int numRotations = get_rotation(int HallNumber,
int rotation[3][3],
double origin_shift[3])

HallNumber is read as input and rotation and origin_shift are populated on output.The length of the rotation and origin_shift arrays is numRotations.

Using the space group “F 4d 2 3 -1d” (#525) there are 192 rotation matrices and origin shift vectors.

Thanks,
Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.sam.pitt.edu

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com

–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com