On Monday 10 of February 2014 09:46:22 Jure Varlec wrote:
Should I merge it with the crystallography
extension? Most of its code merely duplicates the Fill Unit Cell action,
and does it wrong somehow.
Never mind, I just saw there’s a new version on Gerrit. It too produces too
many atoms unless used with P1.
Regards
Jure
took some time. I hit a snag with the supercell extension, since it is not
obvious why it doesn’t work. Should I merge it with the crystallography
extension? Most of its code merely duplicates the Fill Unit Cell action, and
does it wrong somehow.
I had a patch for the supercell extension to merge into the crystallography extension (where it belongs anyway).
http://review.source.kitware.com/#/c/5764/
Please feel free to comment and/or rebase from this. Personally, I thought this best lived under the Crystallography menu, since we could add a nanoparticle builder, nanowire builder, etc.
-Geoff
On Monday 10 of February 2014 07:24:18 Geoffrey Hutchison wrote:
Please feel free to comment and/or rebase from this. Personally, I thought
this best lived under the Crystallography menu, since we could add a
nanoparticle builder, nanowire builder, etc.
I agree wrt. menus. Do I just rebase with git or do I have to do anything
gerrit-specific to record the dependency?
I agree wrt. menus. Do I just rebase with git or do I have to do anything
gerrit-specific to record the dependency?
It seems like you figured that out. I’m not quite sure I understand your comment with the code review. Could you explain that — there’s still an underlying bug?
Also, are there modifications that need to be made with Open Babel?
Thanks,
-Geoff
On Monday 10 of February 2014 11:41:40 Geoffrey Hutchison wrote:
I’m not quite sure I understand your
comment with the code review. Could you explain that — there’s still an
underlying bug?
If you’re referring to the comments I posted on gerrit, it wasn’t really a
bug. My structure was not specified to the precision required by fillUnitCell.
It can be avoided by symmetrizing the cell first. For the cases where the cell
is both imprecise and incomplete, I pushed [1] which also removes the nagging
tolerance dialog.
Also, are there modifications that need to be made with Open Babel?
I don’t think so, but am not yet sure. The most egregious bug was Avogadro’s
use of spacegroup numbers instead of Hall symbols. With that fixed, using
OpenBabel should be OK, provided its conventions match those of Spglib. I will
attempt to compare the transformations in the Spglib database with those of
OpenBabel. If they match, I believe having the cell symmetrized should be
enough; I added [2] to help a newbie like myself, although it is no substitute
for actual documentation. If they don’t match, I’ll let crystallographers
decide how to proceed.
[1] http://review.source.kitware.com/#/c/14359/
[2] http://review.source.kitware.com/#/c/14357/
On Monday 10 of February 2014 18:31:34 Jure Varlec wrote:
With that fixed, using
OpenBabel should be OK, provided its conventions match those of Spglib. I
will attempt to compare the transformations in the Spglib database with
those of OpenBabel.
I did the comparison. Most of the conventions are the same, except for groups
with Hall symbols B -2bc, R 3 -2", F 4d 2 3 and P 4 2 3 -1n. Can a
crystallographer please comment on this? I tried taking a cubic cell, choosing
F 4d 2 3, placing a single atom and calling Fill Unit Cell, which uses
OpenBabel. After that, Perceive Spacegroup, which uses Spglib, detected
F -4c 2 3. I’m not sure what to do about this.
Regards
Jure
Hi Jure,
I have a question though I’m not a crystallographer. What do you mean
“Most of the conventions are the same, except for groups with Hall
symbols B -2bc, R 3 -2”, F 4d 2 3 and P 4 2 3 -1n"?
I tried taking a cubic cell, choosing
F 4d 2 3, placing a single atom and calling Fill Unit Cell, which uses
OpenBabel. After that, Perceive Spacegroup, which uses Spglib, detected
F -4c 2 3. I’m not sure what to do about this.
The choice of axes and origin are arbitrary. So one of equivalent
space group is chosen. I don’t remember if there is a rule or not in
spglib.
Togo
On Tue, Feb 11, 2014 at 8:05 PM, Jure Varlec jure.varlec@ki.si wrote:
On Monday 10 of February 2014 18:31:34 Jure Varlec wrote:
With that fixed, using
OpenBabel should be OK, provided its conventions match those of Spglib. I
will attempt to compare the transformations in the Spglib database with
those of OpenBabel.I did the comparison. Most of the conventions are the same, except for groups
with Hall symbols B -2bc, R 3 -2", F 4d 2 3 and P 4 2 3 -1n. Can a
crystallographer please comment on this? I tried taking a cubic cell, choosing
F 4d 2 3, placing a single atom and calling Fill Unit Cell, which uses
OpenBabel. After that, Perceive Spacegroup, which uses Spglib, detected
F -4c 2 3. I’m not sure what to do about this.Regards
Jure
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com
On Tuesday 11 of February 2014 22:24:21 Atsushi Togo wrote:
I have a question though I’m not a crystallographer. What do you mean
“Most of the conventions are the same, except for groups with Hall
symbols B -2bc, R 3 -2”, F 4d 2 3 and P 4 2 3 -1n"?
I mean to say that for each of the other spacegroups, the transformations
given by spgdb_get_operation are the same as those given by OpenBabel. This is
not so for the four spacegroups noted above.
The choice of axes and origin are arbitrary. So one of equivalent
space group is chosen. I don’t remember if there is a rule or not in
spglib.
As I understand it, the choice is indeed arbitrary, but the transformations
involved change according to this choice. Thus, if OpenBabel uses a different
choice than Spglib, we have a problem. Spglib always takes the entire cell
into account so it should always work corretcly, but OpenBabel does not, it
assumes the cell matches its own conventions. Do I understand correctly?
Regards,
Jure
I mean to say that for each of the other spacegroups, the transformations
given by spgdb_get_operation are the same as those given by OpenBabel. This is
not so for the four spacegroups noted above.
There are many similar words so I need to make it clear. Your
‘transformations’ means a set of symmetry operations of a
space-group-type defined by a hall symbol? If so, spglib or Open babel
made mistake in decoding the hall symbols because the way to decode is
unique.
The choice of axes and origin are arbitrary. So one of equivalent
space group is chosen. I don’t remember if there is a rule or not in
spglib.As I understand it, the choice is indeed arbitrary, but the transformations
involved change according to this choice. Thus, if OpenBabel uses a different
choice than Spglib, we have a problem. Spglib always takes the entire cell
into account so it should always work corretcly, but OpenBabel does not, it
assumes the cell matches its own conventions. Do I understand correctly?
I think you are right.
Togo
Regards,
Jure
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com
On Tuesday 11 of February 2014 22:54:55 Atsushi Togo wrote:
I mean to say that for each of the other spacegroups, the
transformations
given by spgdb_get_operation are the same as those given by OpenBabel.
This is not so for the four spacegroups noted above.There are many similar words so I need to make it clear. Your
‘transformations’ means a set of symmetry operations of a
space-group-type defined by a hall symbol? If so, spglib or Open babel
made mistake in decoding the hall symbols because the way to decode is
unique.
I think we are getting closer to an understanding. Are you saying that when I
specify a Hall symbol, I also implicitly specify a choice of origin etc. and
there should not be any ambiguity left? If so, does spg_refine_cell put the
cell into an appropriate state so that applying operations specified by the
Hall symbol makes sense?
Regards
Jure
Yes, right. As you wrote, spg_refine_cell put the cell into “an
appropriate state”. There are several choices, but spgilb forces to
choose one of them.
A word “transformation” can be used to transform a setting (of axes,
origin, or centring) to another. So I need to make it clear.
Togo
On Wed, Feb 12, 2014 at 12:38 AM, Jure Varlec jure.varlec@ki.si wrote:
On Tuesday 11 of February 2014 22:54:55 Atsushi Togo wrote:
I mean to say that for each of the other spacegroups, the
transformations
given by spgdb_get_operation are the same as those given by OpenBabel.
This is not so for the four spacegroups noted above.There are many similar words so I need to make it clear. Your
‘transformations’ means a set of symmetry operations of a
space-group-type defined by a hall symbol? If so, spglib or Open babel
made mistake in decoding the hall symbols because the way to decode is
unique.I think we are getting closer to an understanding. Are you saying that when I
specify a Hall symbol, I also implicitly specify a choice of origin etc. and
there should not be any ambiguity left? If so, does spg_refine_cell put the
cell into an appropriate state so that applying operations specified by the
Hall symbol makes sense?Regards
Jure
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com
On Wednesday 12 of February 2014 15:11:01 Atsushi Togo wrote:
Yes, right. As you wrote, spg_refine_cell put the cell into “an
appropriate state”. There are several choices, but spgilb forces to
choose one of them.
A word “transformation” can be used to transform a setting (of axes,
origin, or centring) to another. So I need to make it clear.
OK. What I want to make clear: do we expect spglib and OpenBabel to have the
same “appropritate state” for the same Hall symbol, or is it OK for them to
have a different setting? In other words, does a Hall symbol specify the
setting completely, or is there some ambiguity left?
Regards
Jure
Yes. I think there is no ambiguity. But we have to be careful about
that it’s still arbitrary with respect to lattice translation. So for
this, we employ some convention, e.g., translation part (t) of a
symmetry operation is restricted 0 <= t < 1.
The decoding of Hall symbol is not difficult. You can do it following
Concise Space-Group Symbols .
I still have not yet understood what you want to do. But there may be
other ambiguities, or say conventions. For example, there are reverse
and observe settings of hexagonal rhombohedral (hR), which gives 60
degrees difference along c-axis, but gives, I guess, the same set of
symmetry operations for a space group type. So spg_refine_cell always
returns primitive rhombohedral (pR).
Togo
On Wed, Feb 12, 2014 at 5:09 PM, Jure Varlec jure.varlec@ki.si wrote:
On Wednesday 12 of February 2014 15:11:01 Atsushi Togo wrote:
Yes, right. As you wrote, spg_refine_cell put the cell into “an
appropriate state”. There are several choices, but spgilb forces to
choose one of them.
A word “transformation” can be used to transform a setting (of axes,
origin, or centring) to another. So I need to make it clear.OK. What I want to make clear: do we expect spglib and OpenBabel to have the
same “appropritate state” for the same Hall symbol, or is it OK for them to
have a different setting? In other words, does a Hall symbol specify the
setting completely, or is there some ambiguity left?Regards
Jure
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com
On Wednesday 12 of February 2014 17:43:25 Atsushi Togo wrote:
Yes. I think there is no ambiguity. But we have to be careful about
that it’s still arbitrary with respect to lattice translation. So for
this, we employ some convention, e.g., translation part (t) of a
symmetry operation is restricted 0 <= t < 1.
The decoding of Hall symbol is not difficult. You can do it following
Concise Space-Group Symbols .I still have not yet understood what you want to do. But there may be
other ambiguities, or say conventions. For example, there are reverse
and observe settings of hexagonal rhombohedral (hR), which gives 60
degrees difference along c-axis, but gives, I guess, the same set of
symmetry operations for a space group type. So spg_refine_cell always
returns primitive rhombohedral (pR).Togo
Thanks for clarification. I want to do two things. First, learn more about
this topic, and I am very grateful for all your comments. Second, consider
that Avogadro uses spglib to do spacegroup perception, cell refinement and
similar. But it uses OpenBabel to do other things like filling the unit cell.
Spglib cannot be used for this simply because it cannot work with an
incomplete unit cell. Also, OpenBabel’s spacegroup and unit cell functionality
is accessible from anywhere in Avogadro because the data is stored in the
OpenBabel’s molecule structure. Therefore, it would be convenient if spglib
and OpenBabel used compatible conventions.
To clarify further, I will summarize the problem. I assumed (correctly, as you
stated) that spg_refine_cell puts the cell into spglib’s “native” setting. I
then compared the symmetry operations in the spglib database to those in
OpenBabel’s database. I found that they were the same in almost all cases,
except for groups indexed by Hall symbols B -2bc, R 3 -2", F 4d 2 3 and P 4 2
3 -1n". Which means that for these four groups, when we use spg_refine_cell,
we obtain a cell which is not compatible with OpenBabel.
What is worse, I tried taking a cubic cell, choosing F 4d 2 3, placing a
single atom and calling Fill Unit Cell, which uses OpenBabel. After that,
Perceive Spacegroup, which uses Spglib, detected F -4c 2 3. When I repeated
this procedure later, it detected -F 4c 2 3. This kind of thing did not happen
with -P 3*.
I am not sure what to do about this. Do spglib or OpenBabel have incorrect
data? Is it simply a different convention, and if so, what to do about it?
Should we try to use only one of these libraries?
Regards
Jure
To clarify further, I will summarize the problem. I assumed (correctly, as you
stated) that spg_refine_cell puts the cell into spglib’s “native” setting. I
then compared the symmetry operations in the spglib database to those in
OpenBabel’s database. I found that they were the same in almost all cases,
except for groups indexed by Hall symbols B -2bc, R 3 -2", F 4d 2 3 and P 4 2
3 -1n". Which means that for these four groups, when we use spg_refine_cell,
we obtain a cell which is not compatible with OpenBabel.
As I wrote, I think OpenBabel or spglib has wrong database. It’s not a
matter of compatibility.
What is worse, I tried taking a cubic cell, choosing F 4d 2 3, placing a
single atom and calling Fill Unit Cell, which uses OpenBabel. After that,
Perceive Spacegroup, which uses Spglib, detected F -4c 2 3. When I repeated
this procedure later, it detected -F 4c 2 3. This kind of thing did not happen
with -P 3*.
The space group type itself is different. So it can be a bug of
spglib. You can use findsym (http://stokes.byu.edu/iso/isotropy.php)
to determine space group type instead of spglib, and if the result
dones’t agree with spglib, it is highly possible that bug is in
spglib. If the bug in spglib is clear, I will fix it.
Should we try to use only one of these libraries?
I have no idea.
Togo
Regards
Jure
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Atsushi Togo
http://atztogo.github.com/
atz.togo@gmail.com
On Wednesday 12 of February 2014 21:51:25 Atsushi Togo wrote:
To clarify further, I will summarize the problem. I assumed (correctly, as
you stated) that spg_refine_cell puts the cell into spglib’s “native”
setting. I then compared the symmetry operations in the spglib database
to those in OpenBabel’s database. I found that they were the same in
almost all cases, except for groups indexed by Hall symbols B -2bc, R 3
-2", F 4d 2 3 and P 4 2 3 -1n". Which means that for these four groups,
when we use spg_refine_cell, we obtain a cell which is not compatible
with OpenBabel.As I wrote, I think OpenBabel or spglib has wrong database. It’s not a
matter of compatibility.
I finally managed to decipher the notation in the International Tables for
Crystallography. Since you claimed we’re dealing with a bug in one of the
databases, I took a closer look. Indeed, the OpenBabel database is faulty. I
will report a bug shortly.
Togo, thank you for your help!
Regards
Jure