- cctbxbb - phenix-online.org

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 09 Sep '14

09 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 20 Aug '14

20 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

Re: [cctbxbb] resend
by Mustyakimov, Marat 24 Jul '14

24 Jul '14

Loop through symops: apply each symop to the original asu, then apply unit translations to minimize its distance to the original asu, test if new asu intersects with the target 27-bricks-large box, use it, if it does. Keep in mind that asu is not always a brick, it is always a convex polyhedron in cctbx. I do not see any good reason for doing all that. I do not read cctbxbb. On Jul 24, 2014, at 2:43 PM, Alastair Fyfe <afyfe(a)soe.ucsc.edu> wrote: >> Hi Marat, my apologies if this is a duplicate. From Pavel's comment it occurred to me you might not follow posts to the cctxbb >> Alastair >> ------ >> >> Many thanks for your replies. >> >> Pavel : by "slow" I meant to (a) apply sym ops to asu and refer results >> back to unit cell thus obtaining a "full" unit cell (I expect >> "expand_to_p1()" does this?) (b) translate the cell and (c) find overlap >> with the 26-brick neighborhood of the starting brick. This should work >> but seems inefficient. >> >> Marat: applying SymOps to the basis vectors seems a great idea. >> However, it wasn't clear to me how to combine sg SymOps to yield the >> 26 adjacent bricks. Does the map expansion code do this? >> >> >

1 0

Re: [cctbxbb] 26-fold symm expansion of asu?
by Alastair Fyfe 24 Jul '14

24 Jul '14

Many thanks for your replies. Pavel : by "slow" I meant to (a) apply sym ops to asu and refer results back to unit cell thus obtaining a "full" unit cell (I expect "expand_to_p1()" does this?) (b) translate the cell and (c) find overlap with the 26-brick neighborhood of the starting brick. This should work but seems inefficient. Marat: applying SymOps to the basis vectors seems a great idea. However, it wasn't clear to me how to combine sg SymOps to yield the 26 adjacent bricks. Does the map expansion code do this? On 07/23/2014 12:00 PM, cctbxbb-request(a)phenix-online.org wrote: > Send cctbxbb mailing list submissions to > cctbxbb(a)phenix-online.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://phenix-online.org/mailman/listinfo/cctbxbb > or, via email, send a message with subject or body 'help' to > cctbxbb-request(a)phenix-online.org > > You can reach the person managing the list at > cctbxbb-owner(a)phenix-online.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cctbxbb digest..." > > > Today's Topics: > > 1. Re: 26-fold symm expansion of asu? (Pavel Afonine) > 2. Re: 26-fold symm expansion of asu? (Mustyakimov, Marat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Jul 2014 18:58:32 -0700 > From: Pavel Afonine <pafonine(a)lbl.gov> > To: cctbx mailing list <cctbxbb(a)phenix-online.org> > Cc: "Mustyakimov, Marat" <mustyakimovm(a)ornl.gov> > Subject: Re: [cctbxbb] 26-fold symm expansion of asu? > Message-ID: <53CF16C8.5040504(a)lbl.gov> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Alastair, > > I think I can write a piece of code using cctbx that would do what you > want and probably that would be what you call "slow". Could you please > explain some more what it is for and why, and may be give some context? > Perhaps that helps me to see if we have something similar already > available.. > > For instance we have very efficient code that computes maps in ASU, and > also that expands map in ASU into the whole P1 box. This is something > Marat wrote recently and is very efficient. May be you can reuse that or > at least harvest ideas? > > I'm copying to Marat in case he has comments. > > Pavel > > On 7/21/14, 2:14 PM, Alastair Fyfe wrote: >> Hi, >> I'd be grateful for any pointers to clipper or cctbx code that >> addresses the following: given a "brick" of map grid coordinates that >> enclose the asu, obtain the 26 symmetry-related "bricks" which contact >> it. Calculating this by successively generating symmetry mates and >> testing seems slow; I was wondering whether there was a better way. >> thank you, >> Alastair Fyfe >> UCSC >> _______________________________________________ >> cctbxbb mailing list >> cctbxbb(a)phenix-online.org >> http://phenix-online.org/mailman/listinfo/cctbxbb > > > ------------------------------ > > Message: 2 > Date: Wed, 23 Jul 2014 14:01:13 +0000 > From: "Mustyakimov, Marat" <mustyakimovm(a)ornl.gov> > To: Pavel Afonine <pafonine(a)lbl.gov> > Cc: cctbx mailing list <cctbxbb(a)phenix-online.org> > Subject: Re: [cctbxbb] 26-fold symm expansion of asu? > Message-ID: <9457BEEC-4821-4BBB-8D91-E903AAFAE7F0(a)ornl.gov> > Content-Type: text/plain; charset="iso-8859-1" > > The fast way to generate symmetry equivalent ASU: > Apply symmetry operation to unit vectors: ex = SymOp*(1,0,0), ey=SymOp*(0,1,0) and ez=SymOp*(0,0,1); > Then every map point of the symmetry related asu is obtained from the original one: > new_ijk = i*ex + j*ey + k*ez where (i,j,k) is the grid point in the original ASU. > > Marat Mustyakimov > P.O. Box 2008, Bldg. 8600, MS-6475 > Oak Ridge National Lab > Oak Ridge TN 37831 USA > e-mail: mustyakimovm(a)ornl.gov<mailto:[email protected]> > e-mail: marat.mustyakimov(a)gmail.com<mailto:[email protected]> > Tel: +1-865-253-3924 > > On Jul 22, 2014, at 9:58 PM, Pavel Afonine <pafonine(a)lbl.gov<mailto:[email protected]>> wrote: > > Hi Alastair, > > I think I can write a piece of code using cctbx that would do what you want and probably that would be what you call "slow". Could you please explain some more what it is for and why, and may be give some context? Perhaps that helps me to see if we have something similar already available.. > > For instance we have very efficient code that computes maps in ASU, and also that expands map in ASU into the whole P1 box. This is something Marat wrote recently and is very efficient. May be you can reuse that or at least harvest ideas? > > I'm copying to Marat in case he has comments. > > Pavel > > On 7/21/14, 2:14 PM, Alastair Fyfe wrote: > Hi, > I'd be grateful for any pointers to clipper or cctbx code that addresses the following: given a "brick" of map grid coordinates that enclose the asu, obtain the 26 symmetry-related "bricks" which contact it. Calculating this by successively generating symmetry mates and testing seems slow; I was wondering whether there was a better way. > thank you, > Alastair Fyfe > UCSC > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org<mailto:[email protected]> > http://phenix-online.org/mailman/listinfo/cctbxbb > > > > > ------------------------------ > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb > > > End of cctbxbb Digest, Vol 64, Issue 2 > **************************************

1 0

26-fold symm expansion of asu?
by Alastair Fyfe 23 Jul '14

23 Jul '14

Hi, I'd be grateful for any pointers to clipper or cctbx code that addresses the following: given a "brick" of map grid coordinates that enclose the asu, obtain the 26 symmetry-related "bricks" which contact it. Calculating this by successively generating symmetry mates and testing seems slow; I was wondering whether there was a better way. thank you, Alastair Fyfe UCSC

3 2

Phenix dependencies in CCTBX code
by Graeme.Winter＠diamond.ac.uk 22 Jun '14

22 Jun '14

Dear All, In cctbx_project/iotbx/pdb/multimer_reconstruction.py there is a dependency on Phenix from phenix.command_line.simple_ncs_from_pdb import simple_ncs_from_pdb from phenix.command_line.simple_ncs_from_pdb import ncs_master_params Please could someone remove this? I just had a look at cleaning things up so that this was encapsulated but was not obvious and figured risk of breaking was more substantial. This is breaking our nightly build tests at Diamond as we don’t check out phenix :o( 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 1