- cctbxbb - phenix-online.org

Boost.Extension plugins in CCTBX
by Graeme.Winter＠diamond.ac.uk 17 Aug '12

17 Aug '12

Hi Folks, It seems that Boost includes (or may include) a mechanism to allow compiled plugins see for example http://boost-extension.redshoelace.com/docs/boost/extension/boost_extension… - is this in cctbx? is anyone interested in it being available? It seems useful from where I am sat. Thanks, Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

1 0

from __future__ import division has become compulsory
by Luc Bourhis 15 Aug '12

15 Aug '12

Dear cctbx developers, as discussed here a few days ago, it has been decided that every single Python module must feature from __future__ import division A mega commit of mine has just taken care of existing code. For future modules, libtbx.find_clutter will complain if that line is missing. A script libtbx.add_from_future_import_division is provided that can add that line correctly. The rationale is that: i. as you know, we want to use the so-called new division semantics in cctbx modules (i.e. 1/2 == 0.5 instead of 1/2 == 0 as per the old semantics for the record) ii. the current solution passing -Qnew on the Python command line in the dispatchers libtbx.python, cctbx.python, etc is not always appropriate as there are people out there using cctbx as yet-another-library in a context where some code would not correctly run with the new division semantics, therefore barring the use of -Qnew The only solution to reconcile i. and ii. is therefore to add that __future__ line in every single Python module committed to the cctbx. Note however that the aforementioned dispatchers do still use -Qnew so that Phenix developers do not need to put that very line in their Phenix code. Hopefully, we can make everybody reasonably happy with those compromises. Best wishes, Luc

1 0

Deprecation warning?
by Graeme.Winter＠diamond.ac.uk 09 Aug '12

09 Aug '12

Is there a way to avoid this? Using matplotlib.pyplot. /Users/graeme/svn/cctbx_plus/base/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_wx.py:1382: wxPyDeprecationWarning: Using deprecated class PySimpleApp. wxapp = wx.PySimpleApp() Thanks, Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

2 5

Problems compiling cctbx on OS X (10.8.0)
by William G. Scott 04 Aug '12

04 Aug '12

Hi folks: I am having the same problem compiling cctbx stand-alone, or within CCP4. I've posted the error log here: http://fennario.ucsc.edu/~wgscott/temp/cctbx_compile_errors.log Any suggestions what to fix? Thanks. Bill William G. Scott Professor Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA 228 Sinsheimer Laboratories University of California at Santa Cruz Santa Cruz, California 95064 USA

7 17

Invert hand of shelxd res file from cctbx
by Graeme.Winter＠diamond.ac.uk 24 Jul '12

24 Jul '12

Hi Folks, This should be easy but I can't find anything! I have a .res file: [gw56@ws050 fast_ep]$ cat sad_fa.res REM Best SHELXD solution: CC 41.11 CC(weak) 23.51 CFOM 64.62 REM TITL sad_fa.ins SAD in P422 CELL 0.98000 78.17 78.17 37.87 90.00 90.00 90.00 LATT -1 SYMM -Y+1/2,X+1/2,Z+1/4 SYMM -X,-Y,Z+1/2 SYMM Y+1/2,-X+1/2,Z+3/4 SYMM X+1/2,-Y+1/2,-Z+3/4 SYMM Y,X,-Z SYMM -X+1/2,Y+1/2,-Z+1/4 SYMM -Y,-X,-Z+1/2 SFAC SE UNIT 256 SE01 1 0.600227 0.892868 0.042187 1.0000 0.2 SE02 1 0.627518 0.852661 0.427392 0.8667 0.2 SE03 1 0.867409 0.911667 0.394418 0.8420 0.2 SE04 1 0.489761 0.805634 0.391009 0.7279 0.2 SE05 1 0.642792 0.649048 0.369694 0.7172 0.2 SE06 1 0.678879 0.535027 0.477918 0.4571 0.2 SE07 1 0.609207 0.572754 0.421746 0.4212 0.2 SE08 1 0.584526 0.536499 0.322047 0.4154 0.2 SE09 1 0.843063 0.846794 0.480296 0.3831 0.2 SE10 1 0.622429 0.743332 0.157899 0.3604 0.2 SE11 1 0.626114 0.528595 0.644789 0.3590 0.2 HKLF 3 END which I would like to read, invert the hand of and write as a pdb file. I got stuck trying to work through the example / test code. Can someone point me in the right direction? Thanks, Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

4 4

rt_mx inconsistencies
by Luc Bourhis 19 Jul '12

19 Jul '12

Hi fellow cctbx developers, class rt_mx, contrarily to the documentation, does not only hold rotation + translation but any transformation y = M x + t where M is an invertible matrix. As a result, rt_mx can be used to store both space group elements and change-of-basis operators (the latter are in general not rotations). Not the purest design but apart from the recurrent need of improving on the documentation, it has been all right. (1) However, revision 15082 has introduced an inconsistency in the comparison of rt_mx instances related to that divide between rotations and non-rotations. Let's r1 and r2 be rotations and m1 and m2 be non-rotations. After that revision, r1 == r2 works all right r1 == m1 throws an exception m1 == m2 throws an exception As far as I know the problem has been first reported by Phil Evans who provided a very clear regression test. The reason is simple: that revision changed operator== to compare the geometric elements, assuming the compared operators are rotations (and therefore that they have an invariant axis or plane). (2) Another side effect of revision 15082 seems to result in r1 == r2 being true even if r1.t() and r2.t() do not have the same denominator. Before that revision, this comparison used to return false. As part of that revision, one test has been changed from != to == for that very reason. (3) revision 15082 follows revision 14990 that introduces an order on rt_mx intances. That order is used to implement a new symmetry-equivalent pair interaction table and rightly so op1 == op2 is made consistent with op1 < op2 and op1 <= op2 by revision 15082. So I am coming to you to discuss what to do. I am of the opinion that (1) needs fixing. I am also of the opinion that (2) is a good move. Here is what I propose to do: (i) Remove operator <=, >=, <, > from class rt_mx and revert operator== to what it used to be. (ii) Change rot_mx and tr_vec operator== to disregard the value of den() (iii) Introduce a proxy class that wraps around rt_mx and that obeys the ordering introduced by revision 14990 (iv) Rewrite the implementation of the symmetry-equivalent pair interaction table generation to use that proxy instead of directly comparing space group symmetry elements. Basically I propose a very orthogonal design that keeps the core sgtbx pristine except for the fixing of a small but long-standing glitch while encapsulating the feature needed by one single algorithm along with that algorithm. What do you think? Best wishes, Luc Bourhis

3 8

cctbx.miller.complete_array() bug?
by Jan Marten Simons 13 Jul '12

13 Jul '12

Hi, I think I found a bug or missing feature in cctbx.miller.complete_array: As I suppose the complete_array function should check if a set of reflections is complete and add missing indices with the specified values. The bug is now when a set contains symmetrically equivalent reflections e.g. in P4 (1, 0, 2) and (0, 1, 2). The sample code below generates this output for the atached data file: --- f_obs read in: Miller array info: None Observation type: xray.amplitude Type of data: double, size=8 Type of sigmas: None Number of Miller indices: 8 Anomalous flag: False Unit cell: (4, 4, 4.44, 90, 90, 90) Space group: P 4 (No. 75) Systematic absences: 0 Centric reflections: 3 Resolution range: 4.44 1.94109 Completeness in resolution range: 1 Completeness with d_max=infinity: 1 (0, 0, 1) 4.10852771683 (0, 1, 0) 4.34856298103 (0, 1, 1) 10.0 (1, 1, 0) 0.911043357914 (1, 1, 1) 9.12523972288 (0, 0, 2) 5.97578446733 (0, 2, 0) 7.10492786733 (1, 0, 2) 2.17485631709 --- f_obs completed: Miller array info: None Observation type: xray.amplitude Type of data: double, size=9 Type of sigmas: None Number of Miller indices: 9 Anomalous flag: False Unit cell: (4, 4, 4.44, 90, 90, 90) Space group: P 4 (No. 75) Systematic absences: 0 Centric reflections: 3 Resolution range: 4.44 1.94109 (0, 0, 1) 4.10852771683 (0, 1, 0) 4.34856298103 (0, 1, 1) 10.0 (1, 1, 0) 0.911043357914 (1, 1, 1) 9.12523972288 (0, 0, 2) 5.97578446733 (0, 2, 0) 7.10492786733 (1, 0, 2) 2.17485631709 (0, 1, 2) 0.0 ---- sample code ------- obs_file = "Model02.hkl" xtal_symm = crystal.symmetry( unit_cell=(4.000, 4.0, 4.44, 90.0, 90.0, 90.0), space_group_symbol="P 4") # load (integral) intensities from diffraction data from iotbx import reflection_file_reader rfl = reflection_file_reader.any_reflection_file("intensities="+obs_file, ensure_read_access=True) I_obs = rfl.as_miller_arrays(crystal_symmetry=xtal_symm, force_symmetry=False, merge_equivalents=True, base_array_info=None)[0] I_obs = I_obs.discard_sigmas() I_obs.merge_equivalents() f_obs = I_obs.as_amplitude_array() print("\n--- f_obs read in:") f_obs.show_comprehensive_summary() f_obs.show_array() d_max, d_min = f_obs.resolution_range() # add missing reflections with 0.0 intensity (= not observed) f_obs = f_obs.complete_array(d_min=d_min, d_max=d_max, new_data_value=0.0, new_sigmas_value=1.0).sort() print("\n--- f_obs completed:") f_obs.show_comprehensive_summary() f_obs.show_array() ---- end sample code ------- As you can see the index (0, 1, 2) is added with zero amplitude where instead the index (1, 0, 2) should be renamed to (0, 1, 2) as those two are symmetrically equivalent for any tetragonal spacegroup (like P4). So to me it looks like the complete_array method does not honor symmetrically equivalent indices at all, where it should imho. What do you think on this issue? With regards, Dipl. Phys. Jan M. Simons Institute of Crystallography RWTH Aachen University

7 8

Getting r1_factor of miller arrays with different count of miller indices
by Jan Marten Simons 07 Jul '12

07 Jul '12

Hi, I'm facing a new challenge while working with cctbx: Imagine a set of (possibly incomplete) measured intesities, or integrated intensities from xrd powder patterns (I_obs) and a fitting crystal symmetry (xtal_symm). Now if I want to check if a given structure would generate the same intensities. (--> low R1) the following code exibits the problem: # -*- coding: utf-8 -*- from __future__ import division from cctbx import xray from cctbx import crystal from cctbx.array_family import flex from libtbx import Auto obs_file = "Test.hkl" # in shelx hklf4 format xtal_symm = crystal.symmetry( unit_cell=(4.000, 5.4321, 7.531, 90.0, 90.0, 90.0), space_group_symbol="P mm2") trial_structure = xray.structure( special_position_settings=crystal.special_position_settings( crystal_symmetry=xtal_symm), scatterers=flex.xray_scatterer([ xray.scatterer( label="Si", site=(0.0,0.0,0.0), u=0.2)])) # load (integral) intensities from diffraction data from iotbx import reflection_file_reader rfl = reflection_file_reader.any_reflection_file("amplitudes="+obs_file, ensure_read_access=True) I_obs = rfl.as_miller_arrays(crystal_symmetry=xtal_symm, force_symmetry=False, merge_equivalents=True, base_array_info=None)[0] I_obs = I_obs.discard_sigmas() f_obs = I_obs.as_amplitude_array() f_calc = trial_structure.structure_factors(d_min=1.0).f_calc() f_calc.merge_equivalents() R1 = f_calc.r1_factor(f_obs, scale_factor=Auto, assume_index_matching=False) gives: " assert other.indices().size() == self.indices().size() AssertionError " Is there some way to get the R1_factor for this kind of scenario? Cheers and thanks in advance, Jan

4 8

Fast way to enable/disable individual scatterers in structure factor calculation
by Jan Marten Simons 06 Jul '12

06 Jul '12

Hi, I'm looking for a simple and fast way to set individual scatterers to be either included or excluded from structure factor calculation. As I see from the source (structure_factors_direct.h) the selection toggle does not seem to be evaluated for this. Of course an additional check for the selection flag would harm performance in most standard cases, so I'd rather like to have a separate c++ function for this, which could be swapped in for the normal f_calc calculation by a boolean toggle in the python part of f_calc. As I'm not that much into the c++ part of cctbx, I'd really appreciate if somebody more knowledgeable could monkey patch this. Cheers, Jan

2 5

angle derivative of rotation matrix
by David Waterman 29 Jun '12

29 Jun '12

Hi, I'm using the axis_and_angle_as_r3_rotation_matrix method of scitbx.matrix.col in some Python code. Now I need to calculate the first derivative of the rotation matrix with respect to the rotation angle. Is there a function to do that somewhere in scitbx (or elsewhere in cctbx)? I had a brief look around but couldn't find anything that looked hopeful. If there isn't something there already I have some Fortran code from David Thomas that I could adapt to do this. Of course it wouldn't be very efficient in pure Python, and calculating the matrix and its derivative separately, but that's okay for now as the code is just for testing out some ideas. By the way, links to http://skal.planet-d.net/demo/matrixfaq.htm in the documentation (e.g. here<http://cctbx.sourceforge.net/current/c_plus_plus/namespacescitbx_1_1math_1_…>) are broken. I found a document with the same name here: http://vamos.sourceforge.net/matrixfaq.htm, but I have no idea if this has the same content as the original. Cheers -- David

3 4