Re: [cctbxbb] Fail to extend space-group with centring translations
Hi Luc, You can make both examples work like this: from cctbx.sgtbx import * info = space_group_info("P2/a") g = info.group() g.expand_ltr(tr_vec((1,1,1),2).new_denominator(sg_t_den)) from cctbx import sgtbx s = sgtbx.space_group_symbols("P21/c") g = sgtbx.space_group(s) g.expand_ltr(sgtbx.tr_vec((1,0,1),3).new_denominator(sg_t_den)) g.expand_ltr(sgtbx.tr_vec((2,0,2),3).new_denominator(sg_t_den)) Any setting of any crystallographic space group can be processed via sgtbx.space_group, as long as the rotation matrix elements are integers. You may just have to be careful in choosing appropriate "t_den" (translation denominators). All matrices in a given space_group instance have to have the same t_den. I know it can be a hassle, but I don't consider it a practical limitation. Note that sg_t_den is just the default (12). You can set other values if necessary. You cannot change the rotation denominator (fixed at 1) for the matrices processed by sgtbx.space_group. Therefore you cannot work with, e.g. the pseudo-orthorhombic C-centered setting of a hexagonal space group. However, I never came across a situation where this was interesting. It would be possible to rewrite the sgtbx based on boost::rational<int>, but it is a big project. The advantage would be more flexibility, the disadvantage a performance decrease. If there is a strong reason I would go for more flexibility, but so far I've never found this worthwhile. BTW: A more convenient way of adding symmetry operations is: g.expand_smx("x+1/2,y+1/2,z+1/2") Cheers, Ralf ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Hi Ralf,
Hi Luc,
You can make both examples work like this:
[…]
Thanks for your explanations. I was overly pessimistic then and good news anyway! I did not understand the logic of the code at all in fact… Luc
Luc, This is a key item in Ralphs reply: "You cannot change the rotation denominator (fixed at 1) for the matrices processed by sgtbx.space_group. Therefore you cannot work with, e.g. the pseudo-orthorhombic C-centered setting of a hexagonal space group. However, I never came across a situation where this was interesting." If the design of the toolbox is too restrictive to permit the user to invent any closed set of operators they want - well thats the end of it. As we say in the UK, C'est la vie. There were lots of things we would have liked to add to CRYSTALS, but there was no room in Bob Carruthers database, and extending it would have been a major hasle. As you pointed out, there are work-arounds that can be applied by a clever crystallographer, and the less clever ones won't even try to do anything clever. It's a self-limiting situation! Much of what crystal enginners want could be done if Oleg lets the user create an extended atom parameter list, and put this into a new unit cell in P1. Best wishes DAvid Luc Bourhis wrote:
Hi Ralf,
Hi Luc,
You can make both examples work like this:
[…]
Thanks for your explanations. I was overly pessimistic then and good news anyway! I did not understand the logic of the code at all in fact…
Luc
Hi Ralf, just picking on one of your remark.
You cannot change the rotation denominator (fixed at 1) for the matrices processed by sgtbx.space_group. Therefore you cannot work with, e.g. the pseudo-orthorhombic C-centered setting of a hexagonal space group. However, I never came across a situation where this was interesting.
It would be possible to rewrite the sgtbx based on boost::rational<int>, but it is a big project. The advantage would be more flexibility, the disadvantage a performance decrease. If there is a strong reason I would go for more flexibility, but so far I've never found this worthwhile.
If I understand correctly, space_group_type lets the user use any space-group in a non-standard setting defined by a special change of basis. Now your example would require the matrix of change of basis to be rational whereas in the current implementation it can only be integral. At least as far as I understand, from the code and your comments. Thus, the only place where rational numbers would be necessary is in those matrices of change of basis, isn't it? Now, would it be possible to define a new class space_group_irrational_setting which would provide services very similar to space_group_type but accepting non-integral matrices for the change of basis? Luc
participants (3)
-
David Watkin
-
Luc Bourhis
-
Ralf W. Grosse-Kunstleve