- cctbxbb - phenix-online.org

Re: [cctbxbb] Possible contributions to the cctbx
by Luc Bourhis 16 Dec '06

16 Dec '06

On 16 Dec 2006, at 06:53, Ralf W. Grosse-Kunstleve wrote: >> We have not developed those two features yet. Fair enough about the >> smtbx… We can easily mimic the mmtbx, > > I just wanted to say that you are most welcome to start the smtbx > tree under the cctbx SF probject. This is just an offer, I'd be > just as happy if you decide to start the tree somewhere else. Oh, I see! Sorry, I misunderstood you then. Thanks for the offer. It would make sense indeed. Of course, our ultimate goal is to develop the equivalent of Phenix for small molecules, and that would not live on sourceforge.net/projects/cctbx either. > It is technically very easy to leverage the cctbx build system for > other modules (I have at least 20 other modules floating around), > i.e. so that you can say libtbx/configure.py smtbx and you'll have > everything set up (PYTHONPATH, PATH, smtbx.python, etc.). The > problem is it is not documented enough (just Michael > Hohn's notes at http://cci.lbl.gov/~hohn/scitbx-tour.html). I hope > to find time to write more detailed web pages over the holiday break. I would highly appreciate that. By easy you probably mean it boils down to add a few instructions in a config file but my experience is that finding out those in the first place is not easy! Anyway, I am afraid I will come back to you with countless questions when I will start to develop with the cctbx. Thanks again, Luc

1 0

Re: [cctbxbb] Possible contributions to the cctbx
by Ralf W. Grosse-Kunstleve 15 Dec '06

15 Dec '06

Hi Luc, > This is a spin-off from the thread about constrained hydrogen > refinement. On the todo list of our EPSRC project, we have a few more > items which I think would fit well in the cctbx. > > 1) anharmonic thermal displacements. Not only the Gram-Charlier ones > but also about the modelling of atoms disordered over a circle or a > line (as done in Crystals [1]). > > 2) multipolar scattering factors, for charge density studies. These suggestions look quite specific to small molecule crystallography. They make me think it would be best to have a "smtbx" (small molecule toolbox) module (inspired by David's message). Do you have a CVS or SVN repository already? Is it publicly accessible (read only)? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [cctbxbb] constrained hydrogen geometry
by Ralf W. Grosse-Kunstleve 15 Dec '06

15 Dec '06

Hi Luc, > I was trying to figure out whether this interface would be sufficient > and/or necessary for the Hydrogen geometry constraints. I am not > quite sure I understand what is gradient_sum_matrix exactly in fact. gradient_sum_matrix is not directly relevant to the hydrogen problem. The only commonality is the chain rule. Roughly, if you have to variables x, y which are "normally" independent and have gradients df/dx and df/dy, and if under "special circumstances" x becomes a function of y (or vice versa), you have to add up the gradients according to the chain rule. If you work this out for the linear relations given by the symmetry operations, you can cast the result in the form of the "gradient sum matrices". Below is a simple example, by Peter Zwart, constraining the sum of occupancies to one. In the hydrogen case, I'd think you just write down the equations constraining the coordinates to each other. Then study them to apply the chain rule. Done! :) Regarding the interfaces: I usually think about interfaces after I've worked out the math and/or algorithms. It is good to make interfaces as similar as possible, but ultimately "form follows function", as a famous architect taught us. Most importantly, find class, function and variable names that convey meaning even to the "reader" no immersed in the problem. That's more than half the battle. > It is the philosophy of the cctbx, isn't it? You have constructed > the cctbx so as to use it as Python library, relegating C++ to some > sort of assembly language for efficiency. Yes, that's a good viewpoint. > The lack of abstraction in the C++ code of the cctbx I don't know what you mean. :) > (hardly any inheritance, Because it has a large potential for obfuscating what's going on. Inheritance is like salt in the soup. > no advanced genericity) You must have overlooked Boost.Python. :) If that doesn't change your mind, look closer at the implementation of the array algebra header files in scitbx/array_family, including the auto-generated header files in cctbx_build/include. > would require wrapping a lot of the cctbx classes behind > proxies inheriting from abstract types. I find this approach cumbersome and fruitless. I am a big believer in form follows function. Function follows form (design interfaces first) doesn't work for me. I always try to achieve first what I actually want to do, then find a good form for it. > A typical example for me are those classes dealing > with position constraints and ADP constraints. They > are unrelated in C++, cctbx::sgtbx::site_constraints and > cctbx::sgtbx::tensor_rank_2::constraints, although they have both have > the same member functions listed above. Functionally the member functions are unrelated, unless you can come up with a general engine that applies the chain rule automatically to a given function. (Such tools exist, e.g. adolc, but are heavy-duty.) I think it would be counter-productive to tie adp/site constraints code together just because the names of the methods are similar. I consider modularity a more important value. > Of course, from Python, it does not matter, thanks to duck typing: > if two objects answer the same method calls, then they are by all > practical means of the same type. The adp/site constraints are not a good example. We don't want to use them interchangeably. I've tried to use the "functor" idea (unifies interfaces without inheritance) in some places, but even that often turns out to be a struggle. This is especially the case when another person adds on (e.g. cctbx.xray.target_functors). What counts the most in my opinion is to avoid redundancy. That's my most important goal when writing source code, because redundancy hampers progress and multiplies bugs, among other bad things. I'm trying to use all tools available to cut back redundancy. I find both templates and inheritance invaluable and use them where they help reducing redundancy, but I do not see "use templates" or "use inheritance" as goals in their own right. > Our group would be more than happy to contribute them to the cctbx > since we absolutely need them for our project. That's great! I think you can achieve a lot quickly if you limit yourself initially to Python. If you then check in what you have, I'd be happy to walk you through the first few times moving time-critical functionality to C++. Cheers, Ralf By Peter Zwart: Some ideas on how to restrain sums of variables to unity. say we have f(a,b,c) with a(x1) = x1 b(x2) = x2 c(x1,x2) = 1 - x1 - x2 Say we have from the refinement engine the following numerical values (right hand side) for our partial derivatives: df/da = Ga df/db = Gb df/dc = Gc The chain rule says: dq/dx = (dq/du)(du/dx) + (dq/dv)(dv/dx) Thus df/dx1 = (df/da)(da/dx1) + (df/dc)(dc/dx1) = Ga - Gc df/dx2 = (df/db)(db/dx2) + (df/dc)(dc/dx2) = Gb - Gc This gives you the rule to go from the full set of derivatives to the reduced set of derivatives (for the general case): #-------------------------------------------------- def pack_derivatives( g_array ): result = g_array[0:g_array.size()-1 ] result = result - g_array[ g_array.size()-1 ] return result #-------------------------------------------------- You also need to go from a reduced set of parameters to the full set of parameters (for the general case): #-------------------------------------------------- def expand_parameters( x ): result = x.deep_copy() result = result.append( 1 - flex.sum(x) ) return result #-------------------------------------------------- This of course assumes that the 'last' variable is the non unique none during refinement. ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

1 0

Possible contributions to the cctbx
by Luc Bourhis 14 Dec '06

14 Dec '06

This is a spin-off from the thread about constrained hydrogen refinement. On the todo list of our EPSRC project, we have a few more items which I think would fit well in the cctbx. 1) anharmonic thermal displacements. Not only the Gram-Charlier ones but also about the modelling of atoms disordered over a circle or a line (as done in Crystals [1]). 2) multipolar scattering factors, for charge density studies. [1] L. Schröder, D.J. Watkin, A. Cousson, R.I. Cooper, and W. Paulus. Crystals enhancements: refinement of atoms continuously disordered along a line, on a ring or on the surface of a sphere. J. Appl. Cryst., 37:545–550, 2004. Best wishes, Luc

1 0

Re: [cctbxbb] constrained hydrogen geometry
by Ralf W. Grosse-Kunstleve 14 Dec '06

14 Dec '06

Hi Luc, > I have not been able to find any facility to constraint hydrogen > geometry, in the manner of the AFIX in ShelXL I mean. Have I missed > them or would it need to be implemented? They need to be implemented. > In the latter case, I have tried to figure out how this could be > done. I manage to find how position and ADP constraints are handled > by constraint objects featuring methods to return the independent > variables and the gradient with respect to them. Then cctbx/cctbx/ > examples/structure_factor_derivatives_4.py shows how those features > can be used. Would Hydrogen geometry constraint be best handled by > mimicking those special positions constraint? I am not sure. The handling of hydrogens seems more complicated than dealing with the constraints due to symmetry. I just had a quick look at the SHELX manual. I see many special cases. If I had a chance to work on this, I'd start with a Python script emulating some of the cases handled by SHELX, refining a few small structures. After getting a few concrete examples to work, I'd try to generalize the procedures for handling the special cases. I'd switch to C++ only after having fully conquered the math and the bookkeeping in Python, and being sure about the final interfaces. To implement the core refinement, I'd copy and modify cctbx/cctbx/xray/minimization.py. See also phenix/phenix/substructure/hyss/minimization.py, which you can find in the CCI Apps bundle (http://phenix-online.org/download/cci_apps/). Hope this helps. As you can tell, I am not an expert in constrained hydrogen refinement, but I'm very interested in seeing such algorithms in the cctbx (we'd probably want to use them in phenix.refine). Let me know if you feel I can do something to help out. Cheers, Ralf ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com

2 1

constrained hydrogen geometry
by Luc Bourhis 14 Dec '06

14 Dec '06

I have not been able to find any facility to constraint hydrogen geometry, in the manner of the AFIX in ShelXL I mean. Have I missed them or would it need to be implemented? In the latter case, I have tried to figure out how this could be done. I manage to find how position and ADP constraints are handled by constraint objects featuring methods to return the independent variables and the gradient with respect to them. Then cctbx/cctbx/ examples/structure_factor_derivatives_4.py shows how those features can be used. Would Hydrogen geometry constraint be best handled by mimicking those special positions constraint? Cheers, luc

1 0

Re: [cctbxbb] Fail to extend space-group with centring translations
by Ralf W. Grosse-Kunstleve 11 Dec '06

11 Dec '06

> I believe Ralph can handle C-1 Yes, most definitely. There are no rational rotation matrix elements => no problem. > In each pair of tables 4 & 5 and 6 & 7 atomic parameters can be > compared directly. If the P to C transformation is made, all four > tables can be compared by inspection. I believe you can always achieve this even with the cctbx as is. You just may have to transform both structures to some unusual setting. Consider that matrices with rational rotation parts elements are not only relatively expensive to handle, but the corresponding geometry is also highly non-intuitive. I.e. if you transform both structures to avoid the rational rotation parts I bet the comparison is easier to explain and understand. The usual trick is to use space_group_type to go to reference settings, then .niggli_cell() to go to primitive settings, then deal with the extra translations in the primitive settings. Technically it comes down to combining the change-of-basis matrices in the right way, which is easy. > In this case, the referees and editors refused to accept a non standard > SG, so the text of the paper becomes laborious, explaining what would > otherwise have been obvious. If you give change-of-basis matrices from the reference setting (using space_group_type) I think it should be easy to argue the case for presenting the comparison using a convenient frame of reference. Note that the space_group_type has a ".universal_hermann_mauguin_symbol()" method to produce "nice" general space group symbols for any setting that can be handled by the space_group class. We use this in the automatic generation of subgroup graphs. E.g. try this: iotbx.explore_metric_symmetry --unit-cell "68.4 68.4 68.3 109.5 109.4 109.5" --space-group=p1 --graph graph.png For this to work you need graphviz (open source). If you don't have it, here is the resulting png file: http://cci.lbl.gov/~rwgk/tmp/explore_metric_symmetry_graph.png > In higer symmetry SGs it may be easier to compare structures if even more > bizzare SG are invented, or if non-standard origins are used. I don't think it is a problem if you use the right existing tools. :) > Im sure this will be true, and that someone will provide the > user-interface for generating the basis vectors form the new (probably > enlarged) cell and new atomic parameters after the expansion. I'd be happy to help integrate the required additions. > Im sure the SM-tbx folk have more pressing problems to deal with than > worrying about this minority application The core "cctbx" (the module, not the project, see Comp. Comm. Newsletter No. 1) is meant to be a small-molecule toolbox. Please don't view it as "read only", unless you don't want to release your additions as open source. (?) Cheers, Ralf ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

1 0

Re: [cctbxbb] Fail to extend space-group with centring translations
by Ralf W. Grosse-Kunstleve 11 Dec '06

11 Dec '06

Hi Luc, > 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. space_group_type determines the change-of-basis matrix from a given setting to the reference setting. > Now your example would require the matrix of change of basis > to be rational whereas in the current implementation it can only be > integral. The change_of_basis_op class has both rational rotation and rational translation parts, with a common r_den for the 9 rotation matrix elements, and a common t_den for the 3 translation vector elements. The "r_den" is fixed at 1 only for the space_group class. Since space_group_type operates only on space_group objects, the limitation applies here too, but the resulting change-of-basis rotation parts certainly don't have to be integral (that would be a terrible limitation). > 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? You are correct. If you need to handle space groups with rational rotation matrices, the way forward is to implement a new class similar to space_group (I'd go for space_group_rational) with a little bit of cut-and-paste to replicate the group multiplication. However, I don't think it is worth redoing the entire space_group_type implementation to accommodate rational rotation parts. In fact, I think it would be a bad solution because of the runtime impact. Consider that any space group when transformed to the primitive setting will have only integral rotation matrices. I.e. all you need is an algorithm that figures out an "initial" change-of-basis matrix to a (any) primitive setting. Construct a standard space_group object with the transformed symmetry operations and feed it into space_group_type. Multiply the "initial" change-of-basis with the output of space_group_type, done. This way you get the desired generality with a moderate effort, without impacting the performance of the many established algorithms based on space_group. Cheers, Ralf ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited

2 1

Re: [cctbxbb] Fail to extend space-group with centring translations
by Ralf W. Grosse-Kunstleve 11 Dec '06

11 Dec '06

> 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. Could you please outline a plausible example where the current implementation is a serious limitation? > 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. I am sure the cctbx is more flexible. > 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. You can create any P1 cell you want, it is totally trivial: first use e.g. xray_structure.expand_to_p1(), then loop over the translations you want to duplicate the atoms. We can easily add methods to do it in one call. Note that the cctbx is open source, with the possibility of write access to the main source repository. Cheers, Ralf ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1

Re: [cctbxbb] Fail to extend space-group with centring translations
by Ralf W. Grosse-Kunstleve 10 Dec '06

10 Dec '06

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

3 3