February 2015 - cctbxbb - phenix-online.org

dependency on phenix
by Roger Martin 26 Jan '16

26 Jan '16

Hi, looking through http://sourceforge.net/p/cctbx/code/HEAD/tree/trunk/mmtbx/refinement/minimi… shows at line 61 from phenix.refinement import weight_xray_chem and http://sourceforge.net/p/cctbx/code/HEAD/tree/trunk/mmtbx/refinement/occupa… line 134 Is weight_xray_chem.py code that could move to cctbx? (cctbx_project/mmtbx/refinement/weight_xray_chem.py) Are there other cross dependencies?

2 2

Atom selections for distance (embarrassingly simple)
by Morten Grøftehauge 18 Feb '15

18 Feb '15

Hi everyone, I'm trying to do some distance extraction of hetero atoms in pdbs. I've got for model in pdb_obj.hierarchy.models(): for chain in model.chains(): for rg in chain.residue_groups(): for ag in rg.atom_groups(): for atom in ag.atoms(): if atom.hetero == True: print atom.distance(atom) Which prints out 0.0 as expected. But I can't figure out how to, say, measure the distance to an atom in the previous residue (if there is a previous residue). I also noticed something weird in this tutorial: http://cctbx.sourceforge.net/sbgrid2008/tutorial.html They truncate a non-standard amino acid to the beta-carbon but this only works because there's an alternate conformation with a standard amino acid (Cys). So it wouldn't work with a seleno-met for instance (I know there's a convert-to-ala function in mmtbx - I said it was weird, not terrible). Anyway, I hope someone can explain the distances thing for me. I'm sure there are multiple ways of doing it (should I just do a selection of "hetatm" and iterate over them and try to get some distanes?). Cheers, Morten

2 1

Partitioning of Grid/Unit Cell
by Nicholas Pearce 15 Feb '15

15 Feb '15

Hi Everyone, I’m trying to partition a grid/space based on smallest distance to atomic sites - as in a voronoi diagram (http://en.wikipedia.org/wiki/Voronoi_diagram <http://en.wikipedia.org/wiki/Voronoi_diagram>). Is there any code in cctbx that could be used to accomplish this? Thanks, Nick Nicholas Pearce, DPhil Student, Structural Genomics Consortium, University of Oxford

3 2

iotbx xray.reconstructed_amplitude and changed SIGF
by Huw Jenkins 12 Feb '15

12 Feb '15

Hi, This is my first post to this list and I hope I can explain my confusion properly. I have been using iotbx to manipulate data stored in mtz files and found that values in columns that should not have been altered by my code are different in the output mtz file. This seems only to occur when the input mtz file contains DANO, SIGDANO columns. When I run the code below F and DANO in input.mtz and output.mtz are the same but SIGF and SIGDANO are different (shown for 5 reflections listed). Is this expected behaviour? Given that in my understanding that code should just read a mtz file, convert the data to a miller array then write the array back out to a new mtz I would expect the values in the input and output to be identical (within rounding error). Thanks, Huw from __future__ import division import sys from iotbx import mtz from iotbx import reflection_file_reader from iotbx import reflection_file_utils def run(args): mtz_file = reflection_file_reader.any_reflection_file("input.mtz") mtz_as_miller_array = mtz_file.as_miller_arrays() f_obs = mtz_as_miller_array[0] mtz_out = f_obs.as_mtz_dataset(column_root_label="F_iotbx") mtz_out.mtz_object().write("output.mtz") if (__name__ == "__main__"): run(sys.argv[1:]) some reflections from input.mtz are: H K L F_ccp4 SIGF_ccp4 DANO_ccp4 SIGDANO_ccp4 ISYM_ccp4 1 2 2 4.90461 2.31536 0 3.27441 0 1 2 3 186.172 1.86381 119.745 3.84862 0 1 2 4 289.31 3.06709 -5.42197 6.46531 0 1 2 5 378.928 2.7118 87.3381 5.56933 0 1 2 6 540.866 4.38513 46.4155 8.8053 0 The same reflections in output.mtz are: H K L F_iotbx SIGF_iotbx DANOF_iotbx SIGDANOF_iotbx ISYMF_iotbx 1 2 2 4.90461 2.00516 0 4.01032 0 1 2 3 186.172 1.8943 119.745 3.7886 0 1 2 4 289.31 3.15096 -5.42197 6.30192 0 1 2 5 378.928 2.74848 87.3381 5.49695 0 1 2 6 540.866 4.3939 46.4155 8.7878 0

2 2

Jenkins spam imminent (but not now)
by markus.gerstel＠diamond.ac.uk 03 Feb '15

03 Feb '15

Hello everyone, We are currently building a continuous integration setup for cctbx using Jenkins at Diamond. This means Jenkins will run all tests for every source code change. If any test (or the build itself) fails, it will send a notification email to this list. This could result in a number of mails. However they follow a pretty obvious format, so should be easy to filter (and we can fine-tune the spamminess if needed). Mails will start soonishly. -Markus -- 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