- cctbxbb - phenix-online.org

Electron density hitogram from MTZ file
by castro＠biochem.mpg.de 28 Oct '14

28 Oct '14

Hi everybody, I am new in crystallogrphy and in the use of cctbx. I am interested in building a electron density histogram from a mtz file. Could somebody give a hint on how to accomplish this task using cctbx libraries (I am scripting in python)? Let's say that I already have the columns of interest as "miller arrays". Then (I think), a grid (on the real space) needs to be created based on unit cell parameters, to finally make the fft. I think that most of my doubts are about the grid. How small the grid should be with respect to the low-resolution limit? Does the space group information needed or it is enough with the the cell parameters? Is there all ready a routine doing this? Thanks a lot for your help. Marcelino

3 4

which cctbx version is recommended now?
by Marcin Wojdyr 15 Oct '14

15 Oct '14

Hi, we need to pick a version of cctbx for CCP4 for use in phaser and DIALS. The latest logs at cci.lbl.gov/cctbx_build/show_error_summary.cgi?build_tag=2014_10_05_2205 show in all builds: [Errno 2] No such file or directory Traceback (most recent call last): ImportError: __import__("boost_python_meta_ext"): No module named boost_python_meta_ext Is it better to pick older version? Marcin

2 3

Miller arrays from lists of indices
by Oliver Zeldin 06 Oct '14

06 Oct '14

Dear cctbx devs, Does anyone know how to make a miller set from a list of (h, k, l) indices? e.g. [(1,2,3), (34, 1, 45), .... ] Cheers, Oliver -- Dr. Oliver B. Zeldin Brunger Group Stanford University

2 2

new cctbx-plus installers
by Nathaniel Echols 23 Sep '14

23 Sep '14

Hi all-- We now have improved installers for CCTBX with all optional third-party dependencies, including numpy, wxPython, and matplotlib; these are basically just a simplified Phenix installer (minus anything that isn't open-source, obviously). For anyone doing visualization these are probably preferable to the default packages. More useful for doing active development is that since these include the pre-build Python, if you are working directly with the CCTBX sources you can bootstrap from these packages. Yesterday's build is here: http://cci.lbl.gov/cctbx_build/plus_bundles/2014_09_08_0005/ and in general the latest version can be obtained here: http://cci.lbl.gov/cctbx_build/plus_bundles/current although today's build isn't finished yet. The next build will also incorporate IPython. I still need to fix the download page so these are listed alongside the old bundles. Once this is done we'll probably declare an official "release". -Nat

3 5

Tests which randomly pass or fail (nag)
by Graeme.Winter＠diamond.ac.uk 16 Sep '14

16 Sep '14

Hi Folks Quick nag if I may... if people have tests which employ random inputs (e.g. random unit cell, random amplitudes and phases) please could they set a seed or select from some seeds which should give random values which work, or fix their tests so that all random values work (ideally!) That way when tests fail people know something is wrong, rather than everything is fine but the random values drawn are troublesome... Sorry for sounding grumpy! Cheerio 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 1

order bias in flex.random_permutation
by Keitaro Yamashita 11 Sep '14

11 Sep '14

Dear cctbx developers, I happened to notice that the implementation of flex.random_permutation (scitbx/random.h) results in biased order because each element is always swapped with the element randomly selected from entire range of array. For details, please see the second paragraph and the right figure of http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#Implementation_er… I reproduced the plot using flex.random_permutation. Actually this seems to have less impact because flex.random_permutation is rarely used in cctbx or phenix as far as I know. If needed, I would commit the corrected version (using the algorithm in the wikipedia article above). Best regards, Keitaro

2 1

IPython with cctbx
by Oliver Zeldin 08 Sep '14

08 Sep '14

Dear Devs, Has anyone tried to get IPython working with cctbx? I'd really like to be able to use IPython notebooks for examples/tutorials/documented experiments, and was wondering if anyone else had thought the same thing. Cheers, Oli

3 10

Re: [cctbxbb] Sphinx docs for CCTBX
by Nigel Moriarty 19 Aug '14

19 Aug '14

These links don't work for me. On Mon, Aug 18, 2014 at 3:16 PM, Ian Rees <irees(a)lbl.gov> wrote: > I'm using a separate build configuration for the docs. You can view > the nightly results here: > > http://cci-vm-6.lbl.gov:8010/builders/cctbx%2Bdocs-linux-64 > > If you click the first build, you can view the log files for each > step, and view the Sphinx log file by clicking "docs:cctbx stdio", > e.g. > > > http://cci-vm-6.lbl.gov:8010/builders/cctbx%2Bdocs-linux-64/builds/6/steps/… > > I'm working through the warnings now. Mostly missing references and > import errors. > > Ian > > On Fri, Aug 15, 2014 at 8:37 AM, Nathaniel Echols <nechols(a)lbl.gov> wrote: > > On Fri, Aug 15, 2014 at 8:06 AM, Richard Gildea <rgildea(a)gmail.com> > wrote: > >> > >> I had a go at starting to document cctbx.uctbx.unit_cell, which as you > >> know is mainly a Boost.Python extension > >> (https://sourceforge.net/p/cctbx/code/20467/). Before I travel too much > >> further down this route, is this an appropriate way of documenting > >> Boost.Python extensions or is there a better way we can do this? > > > > > > I haven't had enough time to experiment to decide on the best approach. > I > > see three choices - the first is what you've done: > > > > class my_class (ext.my_class) : > > """doc""" > > > > def boosted_function (self, some_argument) : > > """function doc""" > > super(ext.my_class, self).boosted_function(some_argument) > > > > OR (2): > > > > ext.my_class.__doc__ = """doc""" > > ext.my_class.boosted_function.__func__.__doc__ = """function doc""" > > > > OR (3): > > > > put the docstrings in C++ code, for instance: > > > > .def("boosted_function", &my_class::boosted_function, "function doc") > > > > (not sure what the equivalent is for classes but it's probably pretty > > similar) > > > > My opinion is that (1) is much too prone to confusion and API conflicts > > unless we're already using this code structure (and FYI, you broke the > call > > signatures for a couple of methods). (3) is just gross. (2) is also > gross > > but has the virtue of being the least likely to break, and doesn't > require > > modifying C++ files. So I'm inclined to take that approach > > > > (For what it's worth, when modifying a class using the boost.python > > injector, we appear to be able to set __doc__ inside there; see > > iotbx.pdb.hierarchy for an example.) > > > >> It would be good to get the documentation for the core cctbx classes up > >> and running, however several of the core classes (e.g. > >> cctbx.sgtbx.space_group, cctbx.uctbx.unit_cell, flex arrays) are mostly > >> Boost.Python extensions, so it would be good to arrive at a sensible > way to > >> document these extensions. > > > > > > Agreed. I think for flex arrays we will be stuck writing the docstrings > in > > C++ - however since these are relatively stable APIs it should be > reasonably > > straightforward. > > > > -Nat > -- Nigel W. Moriarty Building 64R0246B, Physical Biosciences Division Lawrence Berkeley National Laboratory Berkeley, CA 94720-8235 Phone : 510-486-5709 Email : NWMoriarty(a)LBL.gov Fax : 510-486-5909 Web : CCI.LBL.gov

2 1

real-space symmetry operators
by Nathaniel Echols 18 Aug '14

18 Aug '14

Hi all-- I'm trying to figure out how to orthogonalize symmetry operators given a unit cell, which doesn't seem to be something we have code for. These appear in PDB files in the REMARK 290 section but I haven't been able to find any other software that generates them, and the relationship between the symops and the real-space equivalents is unclear. I assume this is conceptually similar to orthogonalizing fractional coordinates, but unit_cell.orthogonalize() does not quite do what I wanted. In the PDB, for P63 it has this (excerpted): REMARK 290 2555 -Y,X-Y,Z ... REMARK 290 SMTRY1 2 -0.500000 -0.866025 0.000000 0.00000 REMARK 290 SMTRY2 2 0.866025 -0.500000 0.000000 0.00000 REMARK 290 SMTRY3 2 0.000000 0.000000 1.000000 0.00000 which looks like it should be relatively straightforward, but I'm not very good with matrices. Does anyone know the correct math for this? The corresponding rt_mx object from sgtbx looks like this: r=(0.0, -1.0, 0.0, 1.0, -1.0, 0.0, 0.0, 0.0, 1.0) t=(0.0, 0.0, 0.0) (Yes, I realize that there are much easier ways to apply symmetry operators to coordinates, but I want to limit the number of matrix multiplications involved when starting from Cartesian coordinates.) thanks, Nat

3 3

Sphinx docs for CCTBX
by Nathaniel Echols 15 Aug '14

15 Aug '14

Thanks to some superb work by Nader Morshed, Oliver Zeldin, and Ian Rees, we now have automatically updated Sphinx docs for CCTBX: http://cci.lbl.gov/cctbx_docs/ Obviously these are still pretty sparse - right now most of the formal documentation is clustered here: libtbx libtbx.utils libtbx.phil (mostly re-using Ralf's old documentation) cctbx.miller iotbx.pdb (built on Ralf's newsletter article) mmtbx.command_line These are a combination of inline docstrings and separate restructured text files in cctbx_project/sphinx. We have automatically generated rst files for some modules, but others will need to be added manually. In the end I think we'll want to curate every file, but the current layout will get us started. To facilitate additional contributions, I've modifed the installation script for base packages to include a --sphinx option. After setting up CCTBX you can then do this: cd $BUILD libtbx.configure sphinx cd $SRC/cctbx_project/sphinx make html and you will get the full documentation built locally. I am still figuring out how to use Sphinx effectively; it is definitely possible to document Boost.Python extensions but it's not quite as obvious. I don't expect us to retroactively document several hundred thousand lines of code written over a decade, but if we can get the core parts thoroughly covered that will greatly reduce the barrier for new developers. Suggestions for particular modules to focus on are appreciated; I am going to try to cover the basic PDB+reflection file functionality. I encourage anyone doing CCTBX-related development to contribute as you go. (They don't need to be your own APIs, just modules you're reasonably familiar with.) Those of you who already have a ton of undocumented code can expect me to harass you periodically about fixing this. (Note that I've cannibalized at least one newsletter article for this, and continue to do so; we should re-use existing prose descriptions as much as possible without violating copyrights.) -Nat

4 5