- cctbxbb - phenix-online.org

structure_factors_from_map
by Philipp Heuser 09 Jul '07

09 Jul '07

Hi, thanks for the help with my asymmetric unit problem again. However I do have further questions further down my pipeline regarding the backwards fft from the map to structure factors: Am I right if I assume that fft_map = new_array.fft_map(resolution_factor=1/3., symmetry_flags=maptbx.use_space_group_symmetry) real_map = fft_map.real_map() very_new_array=new_array.structure_factors_from_map(map=real_map) #Output1 new_array.show_array() #Output2 very_new_array.show_array() Output1 and Output2 should be identical? They are not... Do I have to consider something, so that they are identical? Thanks and kind regards Philipp -- -------------------------------------------------- Dr Philipp Heuser Postdoctoral fellow EMBL-Hamburg c/o Building 25A, DESY Notkestrasse 85 22603 Hamburg phone: +49 40 89902 188 fax: +49 40 89902 149 mail: philipp.heuser(a)embl-hamburg.de web: www.philipp-heuser.de --------------------------------------------------

1 0

Re: [cctbxbb] Asymmetric Unit with cctbx
by Ralf W. Grosse-Kunstleve 25 Jun '07

25 Jun '07

Hi Phillip, Could you give a brief overview of what you want to do? There are many ways of handling the contiguous asu information, but how much effort a particular approach is worth highly depends on the application. E.g. it is important to understand how important runtime performance is vs. memory use vs. developer time. Note that the contiguous asymmetric units are fully defined in the cctbx.sgtbx.direct_space_asu module (this is behind the asu gallery Peter pointed out). However, the full information for handling all conditions on the facets, edges and vertices is only available in Python. For processing maps this is likely to be too slow, unless you really don't care about runtime. In C++, the contiguous asymmetric units are only used as volumes: cctbx/crystal/direct_space_asu.h, classes float_cut_plane and float_asu, which duplicate some of the Python code. It is not a severe duplication since the facet/edge/vertex conditions are meaningless when working with floating-point numbers and can therefore be dropped. When dealing with grid points in maps you need those conditions somehow, either from some sort of reference table as we have in Python, or by looping over the symmetry operations. Handling the full conditions in C++ would be quite a bit of work, I think. It would be cool to have in general, but so far I didn't have an application important enough to justify the effort. Ralf ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097

2 1

Re: [cctbxbb] Asymmetric Unit with cctbx
by Ralf W. Grosse-Kunstleve 22 Jun '07

22 Jun '07

Hi Phillip, sorry, that was an oversight. Replace - real_map = fft_map.real_map() + real_map = fft_map.real_map_unpadded() and it should print identical values. > Is there any reason for the different sizes of the tag_array and the > real_map? real_map.last() and tag_array.last() show different results. That was exactly the problem. The real_map is padded because of FFT requirements. The tag_array is not. .real_map_unpadded() will make a copy. There will be another copy to restore the padding in .structure_factors_from_map() call. The two copies can be avoided in C++, but it is to cumbersome from Python. Ralf ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

3 2

Re: [cctbxbb] Asymmetric Unit with cctbx
by Ralf W. Grosse-Kunstleve 20 Jun '07

20 Jun '07

Hi Philipp, You can find an expanded version of your script here: http://cci.lbl.gov/~rwgk/tmp/cctbx_examples/2007_06_17/ Use this command to generate a fake mtz file: iotbx.python random_f_calc.py P31 Then this command: iotbx.python mtz_to_map_and_back.py random_f_calcs.mtz FC1 FC2 This illustrates how to convert a manipulated map back to Fourier coefficients (via .structure_factors_from_map()) and write these out in MTZ format. In the example, the map manipulation is simply squaring the map. You can do anything else with the map from Python. For the FFT back to Fourier coefficients, you need a map over the unit cell. For maps, we don't have continuous asymmetric units (the map code pre-dates the ASU gallery). Instead, we have a "tag array" of integer values with the same gridding as the data map. An integer value less than 0 means "this grid point is unique under symmetry", values >= 0 are the 1D indices of the symmetry-related unique point. See the code near the end of mtz_to_map_and_back.py. It shows a loop over the grid points accessing both the tag_array and the real_map. This loop is slow, of course, since it is in Python. It should be fast enough for prototyping, but I'd expect the final version to be implemented in C++, unless your manipulation can be formulated with existing array algebra, e.g. the flex.pow2() in the example, which already runs at C++ speed. Cheers, Ralf ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

2 1

Asymmetric Unit with cctbx
by Philipp Heuser 15 Jun '07

15 Jun '07

Dear all! I am not sure if this is the correct place to ask beginner-questions, how to use cctbx, but I try anyway. I would like to read in a mtz file, and convert it to a density map, which I can modify in real space using the asymmetric unit, and afterwards I would like to convert my modified map back to an mtz file. Currently I am stuck at the point, where I want to reduce the map from the unit cell to the asymmetric unit. from iotbx import mtz from cctbx import miller mtz_filename="./some_mtz_file.mtz" mtz_file = mtz.object(mtz_filename) Miller_array = mtz_file.as_miller_arrays() NEW_ARRAY=Miller_array[0].phase_transfer(Miller_array[1], deg=True) #by the way: what can I do with the mandatory_factors flag? Does grid_step=1 means the grid as a 1A spacing? FFT_map = NEW_ARRAY.fft_map(grid_step=1) Real_map = FFT_map.real_map() I would be happy, if anybody could give me some advice how to do that using the cctbx libaries! Thanks in advance Regards Philipp -- -------------------------------------------------- Dr Philipp Heuser Postdoctoral fellow EMBL-Hamburg c/o Building 25A, DESY Notkestrasse 85 22603 Hamburg phone: +49 40 89902 188 fax: +49 40 89902 149 mail: philipp.heuser(a)embl-hamburg.de --------------------------------------------------

1 0

Re: [cctbxbb] cbflib_ext
by Ralf W. Grosse-Kunstleve 05 Jun '07

05 Jun '07

Hi Jon, Nick Sauter is working on the cbflib extension. He told me the current version is a very incomplete prototype, but that he expects to to have a more comprehensive extension around the end of this month. We are planning to move the source code (cbflib_adaptbx) to SourceForge where it will be freely available. Ralf ----- Original Message ---- From: Jon Wright <wright(a)esrf.fr> To: cctbxbb(a)phenix-online.org Sent: Thursday, May 31, 2007 4:30:38 AM Subject: [cctbxbb] cbflib_ext Hello everypne, google has only one hit for cbflib_ext which is in marIP.py in iotbx.detectors. Any hints as to how I should find it? It does not seem to arrive in the current windows all-in download. Irrelevant perhaps, but I also had the beginnings of a swig wrapping for cbflib which is doubtless going to be incompatible with this one. Thanks, Jon ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

1 0

cbflib_ext
by Jon Wright 31 May '07

31 May '07

Hello everypne, google has only one hit for cbflib_ext which is in marIP.py in iotbx.detectors. Any hints as to how I should find it? It does not seem to arrive in the current windows all-in download. Irrelevant perhaps, but I also had the beginnings of a swig wrapping for cbflib which is doubtless going to be incompatible with this one. Thanks, Jon

1 0

Re: [cctbxbb] mask calculation using mmtbx
by Ralf W. Grosse-Kunstleve 04 Apr '07

04 Apr '07

Hi Celine, The interfaces have changed a lot since we published the example in the newsletter. An updated version is available here: http://cci.lbl.gov/~rwgk/tmp/example_bulk_solvent_mask_2007_04_03_1806.py This is only the mask calculation. The rest of the functionality is incorporated in the f_model.manager (I think it is explained a bit in newsletter No. 5). Let me know if you are still having trouble getting the example to work with the latest cctbx version. Ralf ____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather

1 0

mask calculation using mmtbx
by celine Besnard 03 Apr '07

03 Apr '07

Hi, I am trying to use the cctbx to calclate a mask given a pdb following the exemple given on a newsletter. I am using a windows version of the cctbx extracted from the bundle. But in the exemple, the mask is constructed using the masks.mask_utils function from mmtbx. But I cannot see this function in mmtbx.masks. Is there another function I can use to construct a solvent mask? Thanks for any help Celine Besnard

1 0

How can I do FFT with scitbx.fftpack in python
by 张沈鹏(电子科大大三) 29 Mar '07

29 Mar '07

which function can do fft?the help information as below?but none can do fft........... >>> help(fftpack)Help on module scitbx.fftpack in scitbx: NAME scitbx.fftpack FILE f:\foryou\桌面\fft\cctbx\cctbx_sources\scitbx\scitbx\fftpack.py FUNCTIONS adjust_gridding(...) C++ signature: adjust_gridding(int, int) -> int C++ signature: adjust_gridding(int, int, int) -> int adjust_gridding_triple(...) C++ signature: adjust_gridding_triple(class scitbx::af::small<long,10>, int) -> class scitbx::af::small<long,10> C++ signature: adjust_gridding_triple(class scitbx::af::small<long,10>, int, classscitbx::af::small<long,10>) -> class scitbx::af::small<long,10>-- Hi , I'm Earth-Man.你好，我是地球人。欢迎访问我的博客:http://zsp.javaeye.com/ --张沈鹏

1 0

How can I do FFT with scitbx.fftpack in python
by 张沈鹏(电子科大大三) 29 Mar '07

29 Mar '07

newbie-- Hi , I'm Earth-Man.你好，我是地球人。欢迎访问我的博客:http://zsp.javaeye.com/ --张沈鹏

1 0

Assertion Error in twin target test
by Luc Bourhis 23 Mar '07

23 Mar '07

Hi all, I have modified the least square residual classes in cctbx/xray/ targets.h and cctbx.xray to handle refinement against F^2. In the subsequent tests, the following assertion failure cropped up. It does not feel to me my changes caused it… Luc libtbx.python /Users/luc/Developer/cctbx/cctbx_sources/cctbx/cctbx/ regression/tst_twin_target.py approx_equal eps: 0.5 approx_equal multiplier: 10000000000.0 -0.510137170481 approx_equal ERROR 0 approx_equal ERROR Traceback (most recent call last): File "/Users/luc/Developer/cctbx/cctbx_sources/cctbx/cctbx/ regression/tst_twin_target.py", line 540, in <module> run() File "/Users/luc/Developer/cctbx/cctbx_sources/cctbx/cctbx/ regression/tst_twin_target.py", line 488, in run tst_ls_on_i() File "/Users/luc/Developer/cctbx/cctbx_sources/cctbx/cctbx/ regression/tst_twin_target.py", line 95, in tst_ls_on_i assert approx_equal( (fdif_real-old_derivs[0][N_test])/fdif_real, 0, eps=5e-1) AssertionError

2 1

float error
by Alexander.Schiffer＠sanofi-aventis.com 27 Feb '07

27 Feb '07

Dear all, I am trying to detwin a dataset using mmtbx.xtriage but when I run the program with the following command: mmtbx.xtriage data.mtz n_residues=1341 log=detwin.log hklout=data_detwin.mtz symmetry.action=detwin symmetry.twinning_parameters.twin_law=-h-k,k,-l twinning.twinning_parameters.fraction=0.41 I get this message: Attempting to detwin data ------------------------- Detwinning data with: - twin law: -h-k,k,-l BE WARNED! DETWINNING OF DATA DOES NOT SOLVE YOUR TWINNING PROBLEM! PREFERABLY, REFINEMENT SHOULD BE CARRIED OUT AGAINST ORIGINAL DATA ONLY USING A TWIN SPECIFIC TARGET FUNCTION! Traceback (most recent call last): File "/soft/ccp4/cctbx/cctbx_sources/mmtbx/mmtbx/command_line/xtriage.py", line 5, in <module> xtriage.run(command_name="mmtbx.xtriage", args=sys.argv[1:]) File "/soft/ccp4/cctbx/cctbx_sources/mmtbx/mmtbx/scaling/xtriage.py", line 691, in run out=log) File "/soft/ccp4/cctbx/cctbx_sources/mmtbx/mmtbx/scaling/massage_twin_detwin_data.py", line 330, in __init__ self.final_array = detwinner.detwin_it(alpha=self.params.symmetry.twinning_parameters.fraction) File "/soft/ccp4/cctbx/cctbx_sources/mmtbx/mmtbx/scaling/massage_twin_detwin_data.py", line 197, in detwin_it print >> self.out, "Detwinning the data with fraction %3.2f"%(alpha) TypeError: float argument required Any idea? Best regards, Alexander Build tag: 2007_01_24_2154 Red Hat WS 3 Mit freundlichen Grüßen / Best regards / Cordialement Dr. Alexander Schiffer Sanofi-Aventis Deutschland GmbH S&MA Chemical Sciences Germany Structural Biology Industriepark Hoechst Bldg. G877, Room 029 D-65926 Frankfurt am Main t: +49 69 305 24896 f: +49 69 305 80169 w: www.sanofi-aventis.de ************************************************************************************************************************************************************** Sanofi-Aventis Deutschland GmbH · Sitz der Gesellschaft: Frankfurt am Main · Handelsregister: Frankfurt am Main, Abt. B Nr. 40661 Vorsitzender des Aufsichtsrats: Hanspeter Spek - Geschäftsführer: Dr. Heinz-Werner Meier (Vorsitzender), Dr. Matthias Braun, Hervé Gisserot, Dieter Kohl, Prof. Dr. Dr. Werner Kramer, Dr. Martin Siewert **************************************************************************************************************************************************************

2 1

Re: [cctbxbb] fractional coordinate expansion ... share occupancy
by Ralf W. Grosse-Kunstleve 06 Feb '07

06 Feb '07

Hi Andrew, > My question is what is the best method for generating the correct > distribution of atoms at these points. Naively, one would just > randomly select 30% of the shared points to be aluminums and set the > other 70% as silicon. I doubt that this is ideal. Short answer: there is nothing in the cctbx that would help you directly. I have a past as a zeolite person. My understanding was that the 30%/70% occupancy factors are a way to model spatial averages, as that's all you get from the diffraction experiment. How to handle the overlapping atoms depends highly on the context. E.g. in refinement I'd keep the overlapping atoms but constrain the coordinates to be identical. For graphical presentation I'd probably want to find a nice way to present the mixed occupancy, i.e. I wouldn't want to simply draw two crosses on top of each other. What is your context? Cheers, Ralf ____________________________________________________________________________________ Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail

1 0

Re: [cctbxbb] fractional coordinate expansion ... share occupancy
by Ralf W. Grosse-Kunstleve 05 Feb '07

05 Feb '07

Hi David, > I have provided an example compound with scatterer code below as you > will note the output has overlapping atoms and the resulting 58 points > are not enough to cover the chemical formula. What do I need to do to > fix this? Sorry, I don't understand the question. Could you please explain what you expect to see as the output? Ralf ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

2 1

fractional coordinate expansion ... share occupancy
by David A Carr 02 Feb '07

02 Feb '07

Hello All, Thanks to Ralph's modification in January I have had success with cctbx. Now I have another question. Is there a method in the cctbx for dealing with shared occupancy coordinates? I have a compound where in the reduced cell the x,y,z coordinates for two different atoms are the same and a "sof" fraction is given. What is the best practice for handling such points? I have provided an example compound with scatterer code below as you will note the output has overlapping atoms and the resulting 58 points are not enough to cover the chemical formula. What do I need to do to fix this? Thanks, Andrew **************************************** Dr. D. Andrew Carr George Mason University dcarr2(a)gmu.edu ## ## The following example is ## Na9.52 (Al7.2 Si16.8 O48) (H2 O)5.88 ## DAC 1.12.07 ##--------------------------------------- from cctbx import xray from cctbx import crystal from cctbx.array_family import flex def demo(): crystal_symmetry = crystal.symmetry( unit_cell="13.12,13.57,15.81,90.0,143.0,90.000000", space_group_symbol="C 1 2/m 1") scatterers = flex.xray_scatterer() scatterers.append(xray.scatterer(#element = "Si", label="Si1", site=(0.0042,0.2561,0.0965),occupancy=0.7)) scatterers.append(xray.scatterer(#element = "Al", label="Al1", site=(0.0042,0.2561,0.0965),occupancy=0.3)) scatterers.append(xray.scatterer(#element = "Si", label="Si2", site=(0.3442,0.1125,0.3278),occupancy=0.7)) scatterers.append(xray.scatterer(#element = "Al", label="Al2", site=(0.3442,0.1125,0.3278),occupancy=0.3)) scatterers.append(xray.scatterer(#element = "Si", label="Si3", site=(0.3497,0.1193,0.1355),occupancy=0.7)) scatterers.append(xray.scatterer(#element = "Al", label="Al3", site=(0.3497,0.1193,0.1355),occupancy=0.3)) #--------------------------------------------- # Oxygens #--------------------------------------------- scatterers.append(xray.scatterer(#element = "O", label="O1", site=(0,0.3203,0))) scatterers.append(xray.scatterer(#element = "O", label="O2", site=(0.4292,0.1372,0.2924))) scatterers.append(xray.scatterer(#element = "O", label="O3", site=(-.0283,0.3315,0.1491))) scatterers.append(xray.scatterer(#element = "O", label="O4", site=(0.5,0.1347,0.5))) scatterers.append(xray.scatterer(#element = "O", label="O5", site=(0.1993,0.2072,0.2422))) scatterers.append(xray.scatterer(#element = "O", label="O6", site=(0.308,0,0.0850))) scatterers.append(xray.scatterer(#element = "O", label="O7", site=(-.1454,0.1619,0.0205))) scatterers.append(xray.scatterer(#element = "O", label="O8", site=(0.256,0,0.289))) scatterers.append(xray.scatterer(#element = "Na", label="Na", site=(0.7235,0.2619,0.3904),occupancy=1.19)) scatterers.append(xray.scatterer(#element = "O", label="O9", site=(0.663,0.5645,0.7249),occupancy=0.47)) scatterers.append(xray.scatterer(#element = "O", label="O10", site=(0.304,0,0.686),occupancy=0.53)) icsd_structure = xray.structure( crystal_symmetry=crystal_symmetry, scatterers=scatterers) icsd_structure.show_summary().show_scatterers() print icsd_structure.show_distances(distance_cutoff=2.5) print primitive_structure = icsd_structure.primitive_setting() primitive_structure.show_summary().show_scatterers() print p1_structure = primitive_structure.expand_to_p1() p1_structure.show_summary().show_scatterers() print print "OK" if (__name__ == "__main__"): demo()

1 0

Re: [cctbxbb] set_use_u_iso and set_use_u_aniso
by Ralf W. Grosse-Kunstleve 08 Jan '07

08 Jan '07

> > What are those methods of xray.scatterer for? > > And what are their relation to set_grad_u_iso and set_grad_u_aniso? You can use any combination of u_iso and u_star (anisotropic). We had to make this generalization to accomodate TLS refinement. I.e. there are four combinations, use_u_iso/use_u_aniso false/false, true/false, false/true, true/true. The total Debye-Waller factor is the product dw_iso * dw_aniso. If use_u_iso is false, dw_iso = 1, similarly dw_aniso = 1 if use_u_ansio is false. Unfortunately I didn't find the time yet to eliminate the anisotropic_flag, which is redundant. The main problem is that phaser needs to be changed in many places in order to get rid of the flag. The grad_u_iso and grad_u_ansio control the computation of the gradients. The flags are independent of corresponding use flags. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

set_use_u_iso and set_use_u_aniso
by Luc Bourhis 08 Jan '07

08 Jan '07

What are those methods of xray.scatterer for? Luc

1 1

Re: [cctbxbb] Error in fractional coordinates returned by cctbx
by Ralf W. Grosse-Kunstleve 29 Dec '06

29 Dec '06

> We could add .mod_positive() and .mod_short() methods to flex.xray_scatterer, and > then the corresponding two-liners .sites_mod_positive() and .sites_mod_short() to > xray.structure. I'll put it on my to-do list. Done: http://cci.lbl.gov/cctbx_build/all.html Build 2006_12_28_2147 or later includes the new methods. E.g.: p1_structure = structure.expand_to_p1().sites_mod_positive() HTH, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [cctbxbb] Error in fractional coordinates returned by cctbx
by Ralf W. Grosse-Kunstleve 29 Dec '06

29 Dec '06

> flex.fmod_positive( coordinates, 1 ) > > on the fractional coordinates on your sites. > > Ralf, is there a better way? No, Peter's Python loop over the scatterers is currently the best solution. We could add .mod_positive() and .mod_short() methods to flex.xray_scatterer, and then the corresponding two-liners .sites_mod_positive() and .sites_mod_short() to xray.structure. I'll put it on my to-do list. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Error in fractional coordinates returned by cctbx
by David A Carr 28 Dec '06

28 Dec '06

Hello, I have encountered the following inconsistency when working with cctbx. The compound I am working with is as follows. #Silicon Dioxide Quartz low. #Si O2 #ICSD Coll Number 62410 label="Si", site=(0.4643,0.0,0.6667) label="O", site=(0.411,0.2773,0.7783) unit_cell="4.8430, 4.8430, 5.3480, 90.0, 90.0, 120.0", space_group_symbol="P 32 2 1" The error is can be seen in the below. In the second and third Si lines the z value is not a fraction of the unit. Similarly two of the oxygens are placed outside the unit cell. Why does cctbx place these outside of the unit cell? Number of scatterers: 9 At special positions: 0 Unit cell: (4.843, 4.843, 5.348, 90, 90, 120) Space group: P 1 (No. 1) Label, Scattering, Multiplicity, Coordinates, Occupancy, Uiso Si1 Si 1 ( 0.4643 0.0000 0.6667) 1.00 0.0000 Si1 Si 1 ( 0.0000 0.4643 1.3333) 1.00 0.0000 Si1 Si 1 (-0.4643 -0.4643 1.0000) 1.00 0.0000 O1 O 1 ( 0.4110 0.2773 0.7783) 1.00 0.0000 O1 O 1 (-0.2773 0.1337 1.4450) 1.00 0.0000 O1 O 1 (-0.1337 -0.4110 1.1116) 1.00 0.0000 O1 O 1 ( 0.1337 -0.2773 -0.4450) 1.00 0.0000 O1 O 1 (-0.4110 -0.1337 -0.1116) 1.00 0.0000 O1 O 1 ( 0.2773 0.4110 -0.7783) 1.00 0.0000 Below shows the expected fractional coordinates as expected. Based on the space group P 32 2 1. 0.4643 0.0000 0.6667 0.0000 0.4643 0.3333 -0.4643 -0.4643 0.0000 0.4110 0.2773 0.7783 -0.2773 0.1337 0.4450 -0.1337 -0.4110 0.1116 0.1337 -0.2773 -0.4450 -0.4110 -0.1337 -0.1116 0.2773 0.4110 -0.7783 Any insight into this would be of help. I am hoping to use cctbx as a part of our current software development project. Thanks, D.Andrew Carr dcarr2(a)gmu.edu # Below is the code that generates the error # posted above. #--------------------------------------------------- from cctbx import xray from cctbx import crystal from cctbx.array_family import flex def demo(): crystal_symmetry = crystal.symmetry( unit_cell="4.8430, 4.8430, 5.3480, 90.0, 90.0, 120.0", space_group_symbol="P 32 2 1") scatterers = flex.xray_scatterer() scatterers.append(xray.scatterer( label="Si", site=(0.4643,0.0,0.6667))) scatterers.append(xray.scatterer( label="O", site=(0.411,0.2773,0.7783))) icsd_structure = xray.structure( crystal_symmetry=crystal_symmetry, scatterers=scatterers) print "ICSD Structure" icsd_structure.show_summary().show_scatterers() print icsd_structure.show_distances(distance_cutoff=2.5) print "Primitive" primitive_structure = icsd_structure.primitive_setting() primitive_structure.show_summary().show_scatterers() print p1_structure = primitive_structure.expand_to_p1() p1_structure.show_summary().show_scatterers() print print "Expanded to P1" icsd_structure.expand_to_p1().show_summary().show_scatterers() print "OK" if (__name__ == "__main__"): demo()

3 8

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

Fail to extend space-group with centring translations
by Luc Bourhis 09 Dec '06

09 Dec '06

Hello there, with the latest cctbx release, the following Python snippet fails from cctbx.sgtbx import * info = space_group_info("P2/a") g = info.group() g.expand_ltr(tr_vec((1,1,1),2)) The exception indicates that it is not possible to add a centring translation with a denominator of 2 to a group which does not have any centring translations with that denominator. Of course, in that case, that description is trivial because P2/a does not have any centring translations! My real intent was actually to introduce 1/3 centring translations so as to deal with a tripled cell. I am just citing the example above to show the extent of the problem. My original, failing, snippet was therefore 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)) g.expand_ltr(sgtbx.tr_vec((2,0,2),3)) It fails with the same class of exception. It seems like it is a deeply rooted limitation and that brings me to the bigger picture. I am currently working on an EPSRC grant to write the next generation of small molecule crystallographic software, a joint collaboration between Judith Howard in Durham and David Watkin in Oxford (all in UK, just in case…!). The CCTBX is obviously a seducing foundation for such a project. Thus we have tried to push it into corners which do actually matter to a significant minority of small molecule crystallographers. So I would like to know how difficult it would be to lift the limitation at hand. Would it trigger a cascade of changes throughout the sgtbx? Luc Bourhis

2 2

Obtaining symmetry information
by Konrad Hinsen 04 Dec '06

04 Dec '06

Dear All, I am trying to reconstruct an entire unit cell from an cctbx.xray.structure object that contains the scatterers in the asymmetric unit. Ideally, I'd call a method that does the work for me, but at least I would like to obtain a list of the symmetry transformations that must be applied. That information must be somewhere in there... but where? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: hinsen(a)cnrs-orleans.fr ---------------------------------------------------------------------

3 3

compiling problem with latest cctbx on OS X
by William Scott 30 Aug '06

30 Aug '06

With Ralf and Erik's help and advice, (cf http://www.phenix- online.org/pipermail/cctbxbb/2005-September/thread.html ) I made a Mac OS X fink package for the cctbx source release. http://pdb.finkproject.org/pdb/search.php?summary=cctbx Everything works fine on OS X v. 10.4, gcc 4.0.1, on both ppc and intel platforms, until today when I realized the package I made is now out of date (as of July I think). I'm now having problems compiling the latest version. I've put the log file here: http://xanana.ucsc.edu/~wgscott/kipaut/fink/compile.log Briefly, I think the failure is taking place here: c++ -o cctbx/translation_search/boost_python/fast_nv1995.o -c -fPIC - no-cpp-precomp -ftemplate-depth-130 -Wno-long-double -w - DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-math - DBOOST_PYTHON_MAX_BASES=2 -I/sw/src/fink.build/cctbx-60705-1001/ cctbx_sources/boost -Iinclude -I/sw/src/fink.build/cctbx-60705-1001/ cctbx_sources/include -I/sw/src/fink.build/cctbx-60705-1001/ cctbx_sources/cctbx/include -I/sw/src/fink.build/cctbx-60705-1001/ cctbx_sources/scitbx/include -I/sw/src/fink.build/cctbx-60705-1001/ cctbx_sources -I/Library/Frameworks/Python.framework/Versions/2.4/ include/python2.4 /sw/src/fink.build/cctbx-60705-1001/cctbx_sources/ cctbx/translation_search/boost_python/fast_nv1995.cpp /sw/src/fink.build/cctbx-60705-1001/cctbx_sources/scitbx/include/ scitbx/fftpack/complex_to_complex.h: In member function 'void scitbx::fftpack::complex_to_complex<RealType, ComplexType>::pass3 (scitbx::fftpack::select_sign<Tag>, size_t, size_t, RealType*, RealType*, const RealType*, const RealType*)': /sw/src/fink.build/cctbx-60705-1001/cctbx_sources/scitbx/include/ scitbx/fftpack/complex_to_complex.h:361: error: expected unqualified- id before numeric constant Any suggestions? Thanks. Bill Scott

2 6

Generate atom data from cctbx
by Jen-Chang Chen 16 Jan '06

16 Jan '06

Dear Sirs, I have installed "cctbx" in my Linux box and ran the examples,e.g. the beach in the box and the Cr2O3 case demonstrated in the mailing list, successfully. I'd like to apply cctbx as a generator of the crystallographic data. Based on the ICSD database, I can obtain a crystal structure of a mineral. Would it be possible to print out all atom positions in a unit cell or a supercell using cctbx? Thank you very much. Sincerely, Jen-Chang "James" Chen

2 1

Re: [cctbxbb] Problems with conversion from conventional to primitive cell
by Jörg-Rüdiger Hill 25 Nov '05

25 Nov '05

Thanks for your script. I am doing this in C++. I can't find a xray::structure class in the C++ documentation. Does this only exist in Python ? Nevertheless, I run your script in Python and the result is somewhat different from what I get, but I still think it is wrong. If I create and visualize a supercell from the coordinates given by the script (e. g., with gdis) I no longer see the hexagonal arrangement of the atoms typical for the conventional cell. Since the conversion from conventional to primitive cell should only redefine the cell but not the atom positions (in Cartesian coordinates) I believe the output is incorrect. Best Regards, Jörg-Rüdiger Hill >--- J?rg-R?diger Hill <Joerg-Ruediger.Hill(a)scienomics.com> wrote: >> Dear All, >> I am trying to convert from a conventional cell to a primitive cell using >> cctbx, but I am having some problems. > >Are you doing this in C++ or in Python? > >> What I do is the following: >> 1) I construct a spaceGroup object using the space group symbol >> 2) I retrieve the change of basis operator using z2p_op() from the space >> group object >> 3) I apply this operator to the conventional cell >> 4) I take a list of symmetry unique atoms and apply the operator to their >> fractional coordinates >> At this point I have a primitive cell which agrees exactly with what I get >> from other codes. > >Note that there are ambiguities in the choice of the change-of-basis operator >to the primitive cell. You may get different results from different programs, >which are all correct. It is a coincidence if you get the same result. > >> The problem comes when I am trying to construct all atoms >> from the symmetry unique ones. I do this by the following procedure: >> 5) I take the space group object and call its change_basis() method with >> the z2p_op() operator >> 6) I loop over all order_z() symmetry operations in the space group >> applying the operation to the fractional coordinates making sure that I >> don't create two atoms at the same position > >You could use the site_symmetry and sym_equiv_sites classes to deal with the >special positions. > >> The whole procedure works well, e. g., for cubic crystals. However, if I >> take a hexagonal crystal (e. g., Cr2O3, R -3 c) the crystal build by steps >> 5 and 6 above is not correct. In this case the conventional cell has a=b != >> c, >> alpha=beta=90, and gamma=120, but the primitive cell has a=b=c and >> alpha=beta=gamma. > >That's what I'd expect. > >> I have tried to add ":R" to the space group symbol and >> constructing a new spaceGroup object in step 5 above, but that does not >> make any difference. What do I have to do to build the crystal in this case >> or what is wrong with my procedure ? > >Attached is a copy of the new cctbx/cctbx/examples/cr2o3_primitive_cell.py >script (in the CVS already; will also be in the next set of auto-build >bundles). Could you please compare your results to the output of this script? > >The script shows a high-level implementation. I could add a lower-level >equivalent that is more in line with what you'd do in C++. Let me know if > this is what you need. > >Cheers, > Ralf > > >from cctbx import xray >from cctbx import crystal >from cctbx.array_family import flex > >def demo(): > """ > Result of ICSD query: > N * -Cr2O3-[R3-CH] Baster, M.;Bouree, F.;Kowalska, A.;Latacz, Z(2000) > C 4.961950 4.961950 13.597400 90.000000 90.000000 120.000000 > S GRUP R -3 C > A Cr1 0.000000 0.000000 0.347570 0.000000 > A O1 0.305830 0.000000 0.250000 > """ > crystal_symmetry = crystal.symmetry( > unit_cell="4.961950 4.961950 13.597400 90.000000 90.000000 120.000000", > space_group_symbol="R -3 C") > scatterers = flex.xray_scatterer() > scatterers.append(xray.scatterer( > label="Cr1", site=(0.000000,0.000000,0.347570))) > scatterers.append(xray.scatterer( > label="O1", site=(0.305830,0.000000,0.250000))) > icsd_structure = xray.structure( > crystal_symmetry=crystal_symmetry, > scatterers=scatterers) > icsd_structure.show_summary().show_scatterers() > print > icsd_structure.show_distances(distance_cutoff=2.5) > print > primitive_structure = icsd_structure.primitive_setting() > primitive_structure.show_summary().show_scatterers() > print > p1_structure = primitive_structure.expand_to_p1() > p1_structure.show_summary().show_scatterers() > print > print "OK" > >if (__name__ == "__main__"): > demo() -- ------------------------------------------------------------------------------- Dr. Jörg-Rüdiger Hill Tel.: +33 1 53 43 51 05 Director R & D Tel. (direct): +49 89 613 05 700 Scienomics Fax: +33 1 53 43 92 92 17 Square Edouard VII E-Mail: Joerg-Ruediger.Hill(a)scienomics.com 75009 Paris, France Web: http://www.scienomics.com/ -------------------------------------------------------------------------------

2 1

Problems with conversion from conventional to primitive cell
by Jörg-Rüdiger Hill 24 Nov '05

24 Nov '05

Dear All, I am trying to convert from a conventional cell to a primitive cell using cctbx, but I am having some problems. What I do is the following: 1) I construct a spaceGroup object using the space group symbol 2) I retrieve the change of basis operator using z2p_op() from the space group object 3) I apply this operator to the conventional cell 4) I take a list of symmetry unique atoms and apply the operator to their fractional coordinates At this point I have a primitive cell which agrees exactly with what I get from other codes. The problem comes when I am trying to construct all atoms from the symmetry unique ones. I do this by the following procedure: 5) I take the space group object and call its change_basis() method with the z2p_op() operator 6) I loop over all order_z() symmetry operations in the space group applying the operation to the fractional coordinates making sure that I don't create two atoms at the same position The whole procedure works well, e. g., for cubic crystals. However, if I take a hexagonal crystal (e. g., Cr2O3, R -3 c) the crystal build by steps 5 and 6 above is not correct. In this case the conventional cell has a=b != c, alpha=beta=90, and gamma=120, but the primitive cell has a=b=c and alpha=beta=gamma. I have tried to add ":R" to the space group symbol and constructing a new spaceGroup object in step 5 above, but that does not make any difference. What do I have to do to build the crystal in this case or what is wrong with my procedure ? Best Regards, Jörg-Rüdiger Hill -- ------------------------------------------------------------------------------- Dr. Jörg-Rüdiger Hill Tel.: +33 1 53 43 51 05 Director R & D Tel. (direct): +49 89 613 05 700 Scienomics Fax: +33 1 53 43 92 92 17 Square Edouard VII E-Mail: Joerg-Ruediger.Hill(a)scienomics.com 75009 Paris, France Web: http://www.scienomics.com/ -------------------------------------------------------------------------------

2 1

mmtbx source tree moved to SourceForge CVS
by Ralf W. Grosse-Kunstleve 25 Oct '05

25 Oct '05

Today we've finally moved the mmtbx source tree from our private CVS server (cci.lbl.gov) to SourceForge. **** Old working copies checked out from cci.lbl.gov are no longer valid and should be removed. **** To check out a new working copy from SourceForge: Developer access: cvs [email protected]:/cvsroot/cctbx co -P mmtbx replace "user" with your SourceForge user name. Anonymous access: cvs -d:pserver:[email protected]:/cvsroot/cctbx co -P mmtbx It may take a few hours before the anonymous access is available and before the mmtbx tree is visible in the viewcvs web interface. For the records: we were hesitant to move more source trees to SourceForge because the CVS server was often heavily overloaded; a cvs update could take a significant amount of time. However, a recent hardware upgrade at SourceForge has improved performance dramatically. Performance has been very good for a couple of months. Therefore we feel it is a good opportunity to finally move the mmtbx sources to the proper place. This way, browsing the tree via viewcvs is available to everybody, and the automatic archiving of cvs activities (via email) should now work reliably for all developers. Cheers, Ralf __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

strange silicon
by Marc Gailhanou 18 Oct '05

18 Oct '05

Hello, I have some trouble with cctbx, I try to understand why and I do not succeed. I need your help ! I replaced quartz with silicon in the "beach in the box" example/tutorial. This is the resulting code : from cctbx import xray from cctbx import crystal from cctbx.array_family import flex silicon_structure = xray.structure( special_position_settings=crystal.special_position_settings( crystal_symmetry=crystal.symmetry( unit_cell=(5.4307,5.4307,5.4307,90,90,90), space_group_symbol="Fd3m")), scatterers=flex.xray_scatterer([ xray.scatterer( label="Si", site=(0.,0.,0.), u=0) ])) silicon_structure.show_summary().show_scatterers() for scatterer in silicon_structure.scatterers(): print "%s:" % scatterer.label, "%8.4f %8.4f %8.4f" % scatterer.site site_symmetry = silicon_structure.site_symmetry(scatterer.site) print " point group type:", site_symmetry.point_group_type() print " special position operator:", site_symmetry.special_op() f_calc = silicon_structure.structure_factors(d_min=1).f_calc() f_calc.show_summary().show_array() and running the script gives the following result result : Number of scatterers: 1 At special positions: 1 Unit cell: (5.4307, 5.4307, 5.4307, 90, 90, 90) Space group: F d -3 m :2 (No. 227) Label, Scattering, Multiplicity, Coordinates, Occupancy, Uiso Si Si 16 ( 0.0000 0.0000 0.0000) 1.00 0.0000 Si: 0.0000 0.0000 0.0000 point group type: -3m special position operator: 0,0,0 Miller array info: None Observation type: None Type of data: complex_double, size=9 Type of sigmas: None Number of Miller indices: 9 Anomalous flag: False Unit cell: (5.4307, 5.4307, 5.4307, 90, 90, 90) Space group: F d -3 m :2 (No. 227) (0, 2, 2) 0j (0, 4, 0) (120.217658126+0j) (1, 1, 1) (-84.1884955081+0j) (1, 3, 1) (65.4837172721+0j) (1, 3, 3) (57.4543830832+0j) (1, 5, 1) (-51.4875968695+0j) (2, 2, 2) (128.545406989+0j) (2, 4, 2) 0j (3, 3, 3) (-51.4875968695+0j) The 220 structure factor, at least, does not look correct . I do not understand the 16 multiplicity either. Is there something I miss ? Best regards Marc

2 3

Re: [cctbxbb] differing build and install directories?
by Ralf W. Grosse-Kunstleve 29 Sep '05

29 Sep '05

Hi Bill, Sorry that I dropped the ball on this question before. Erik outlines the best way of creating a portable cctbx bundle, but in this case there may be a simpler alternative: - simply cp -r the installation into the final destination - re-run python .../libtbx/configure.py mmtbx in the new build directory location. This will update all full paths. Note though that this simple approach will preserve all intermediate files created by the build procedure (i.e. all the .o files and some auto-generated C++ files). But please try this out first. If it does what you want we can think about ways of getting rid of the unwanted files. > The other issue is that I need to hard-code in the DYLIB path I hope that we don't have to do this, although I'd be willing to modify the central SConscript to optionally support hard-coded paths if there really is no alternative. > instead > of relying on an environment variable, which I am not allowed to set. All cctbx commands on PATH go through "dispatchers". To see how it works, look at any of the auto-generated scripts in the "bin" subdirectory of the build directory. The dispatchers are basically all the same; only the last few lines differ. Each dispatcher updates PYTHONPATH and DYLD_LIBRARY_PATH "just in time" to finally start the target command. I.e. there are no permanent settings in the environment. You just have to add the "bin" directory to PATH if you don't want to type the full path name to each command all the time (which will also work). Is this going to work for you? Cheers, Ralf

4 4

differing build and install directories?
by William Scott 28 Sep '05

28 Sep '05

Dear Ralf: Sorry to keep pestering you. I'm now trying to build debian packages, which means the build directory differs from the install directory. Because of this, a lot of the shell scripts, python scripts, and compiled binaries in cctbx have a path like /sw/src/fink.build/ ccp4-5.99.3-1/ccp4-5.99.3 hard-coded into them, and I'd like the final one to look like /sw/share/xtal/ccp4-5.99.3 (for example). Similarly for Debian linux. Is there a simple way to build in one directory but use the final install-path for configuring? I've tried changing $install_root in the file cctbx_install_script.csh, but that didn't work. Similarly, I noticed the install_paths hard-coded into the dynamic libraries for cctbx are relative, rather than absolute like the others, for examle: % otool -L cctbx_dmtbx_ext.so cctbx_dmtbx_ext.so: /System/Library/Frameworks/Python.framework/Versions/2.3/ Python (compatibility version 2.3.0, current version 2.3.5) lib/libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Is there a simple way to change that? All the best, Bill William G. Scott Associate Professor Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA Sinsheimer Laboratories University of California at Santa Cruz Santa Cruz, California 95064 USA

2 3

Testing.....
by Erik Mckee 27 Sep '05

27 Sep '05

Hello :) Does this work? I'm surprised there aren't any test messages in the archives before now.... However, perhaps I'm just talking to myself here..... *Tests for echo.....

2 1