January 2021 - cctbxbb - phenix-online.org

Find nearest orthonormal matrix
by Robert Oeffner 25 Jan '21

25 Jan '21

Does the CCTBX has a routine for that? I didn't find anything in the scitbx module. But I came across a procedure online here: http://people.csail.mit.edu/bkph/articles/Nearest_Orthonormal_Matrix.pdf If not already in the CCTBX I plan to include a pythonic version of it within the next few days. Rob -- Robert Oeffner, Ph.D. Research Associate, The Read Group Department of Haematology, Cambridge Institute for Medical Research University of Cambridge Cambridge Biomedical Campus The Keith Peters Building Hills Road Cambridge CB2 0XY www.cimr.cam.ac.uk/investigators/read/index.html tel: +44(0)1223 763234 -- This email has been checked for viruses by AVG. https://www.avg.com

3 2

(not really cctbx: PHENIX release bundle content: .o files)
by Winter, Graeme (DLSLtd,RAL,LSCI) 25 Jan '21

25 Jan '21

Hi All, Could not think of a better place to ask this question Installed a PHENIX update this morning and noticed it is quite a substantial download - hard to avoid, in this modern day. While unpacking I noticed it contained a lot of object files - totting it up seems to be ~ 450 MB of .o files which are probably not useful for the average end user. Just wondered, are these worth stripping out before making the release bundles? I note the same is true for DIALS so I am not claiming some moral high ground here & also https://github.com/dials/dials/discussions/1563 … looks like my colleagues decided to pick up on this & happened to agree Just thought worth asking Cheers 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

Space-saving tips
by Tristan Croll 25 Jan '21

25 Jan '21

Hi all, Following on from Graeme's email about .o files, another way to quite dramatically reduce the size of the distribution (with little impact on code complexity or performance) would be to keep all the various text-based data files in .zip format. With modern Python fetching the data from these is little different from working with uncompressed files anyway (1-2 extra lines of code, generally negligible runtime cost). A couple of snippets as an example from ISOLDE (where I keep all MD ligand definition files in a .zip): To get a list of the file contents: def _ligand_db_from_zip(self, ligand_zip): from zipfile import ZipFile import os namelist = [] with ZipFile(ligand_zip) as zf: for fname in zf.namelist(): name, ext = os.path.splitext(fname) if ext.lower() == '.xml': namelist.append(name) return namelist To read a given file from the zip as needed: if ligand_db is not None: zip, namelist = ligand_db if name in namelist: from zipfile import ZipFile logger.info('Loading residue template for {} from internal database'.format(name)) with ZipFile(zip) as zf: with zf.open(name+'.xml') as xf: forcefield.loadFile(xf) Even just doing this for the CaBLAM contour data cuts about 160 MB off the size of the uncompressed distribution. Best regards, Tristan

1 0

Cleaning clutter / pre-commit hooks
by Winter, Graeme (DLSLtd,RAL,LSCI) 25 Jan '21

25 Jan '21

Greetings cctbxbb Was reminded a moment ago about clutter and pre-commit hooks and wondered if there was merit in revisiting this question for cctbx? Not suggesting that pre-commit hooks should be mandatory (though you can git commit -n even if they are) but thinking that it would be a useful way of avoiding doubling up on commits and “failed builds” due to clutter Welcome viewpoints If consensus is not against the use of pre-commit hooks we can try and adapt some from e.g. dials for use here but I would not bother with this if people prefer to manually remove clutter Cheers Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

1 0