Thursday, 19 August 2010

Wanted: Beta testers for new conformation generator

Update 21/08/2010: I've found enough beta testers for the moment - thanks to all those who volunteered.

I'm looking for beta testers for Confab, a new conformation generator I've been working on over the last while. It's based on Open Babel and aims to generate diverse low energy conformations. In particular I am interested in feedback on what sort of features should be added.

If you have access to a Windows system and are interested trying out Confab, please send me an email at baoilleach@gmail.com and I'll follow up with download instructions.

Note: The software is open source (GPL v2) and the source is available on the fastconf branch (commit b9300dd) at http://github.com/baoilleach/openbabel-svn-mirror.

Image credit: dalbera

Tuesday, 17 August 2010

Why a wiki does not work well for documentation - and what you can do about it

I've been working on moving documentation from the Open Babel wiki (Mediawiki) to a Sphinx-based system, and it's really so much better.

Wikis are great because they have a low barrier to contribution, make it easy to collaborate on documentation and (less importantly) have versioning. Wiki are rubbish because they don't impose a hierachical structure (they have some ideas about categories, but that's just not enough), pages get orphaned, and never get read. (They don't look great either, without a lot of customisation.)

Take, for example, the Open Babel wiki. Over the years a lot of effort has gone into creating content. However, there are many pages on the wiki I simply have never seen before because there is no clear path to them from the front page.

So, what to do?

As I said, I've been moving the docs into Sphinx (either manually, or using Pandoc). This uses a simple markup, reStructuredText (reST), to highlight headings, links and so forth. Most importantly it imposes a hierarchy - only pages that are included in a table of contents get incorporated into the documentation. The best part of all is that unlike a wiki (or at least, unlike Mediawiki) Sphinx can output not only HTML, but also LaTeX (for making PDFs) and HTMLHelp (for Windows CHM files).

But it's not a wiki any more, you're thinking. Well actually, that's where you'd be wrong. Through the magic of the internets, if you store your source code on Github, you have a de facto wiki, because reStructuredText is understood by Github and rendered reasonably well. You can click "Edit" right there on Github, edit the source and immediately see the result (and it's versioned of course).

An in-progress version of the Open Babel user documentation is available here, and you can check out the source code on Github (and fork it too, if you want).

Image credit: Ross Mayfield

Friday, 6 August 2010

Open Babel Quick Reference

Hans de Winter of Silicos has put together a quick reference for the Open Babel API on a double-sided A4 page:
If you're at EuroQSAR in September, you can pick up a copy in person. There may also be a few at the Boston ACS. Otherwise, here's the PDF.

Thursday, 29 July 2010

Roger's next move, and speeding up Python code by indenting

I met Roger Sayle the other day and he was showing me some of the work he's been doing recently since leaving OpenEye. Apart from OpenEye, you may remember Roger from such programs as Rasmol and also GCC (he's the middle level maintainer; this is apparently the part that fixes your code to be more efficient - see this quiz for examples). He's also the author of the only paper in JCIM to contain Klingon, the Lexichem paper (incidentally this is also, as far as I know [1], the only paper in JCIM that is freely available through Author Choice).

Early this year, Roger set up NextMove Software which is still in early days but is one to keep an eye on. It currently has software to aid in checking and correcting the spelling of chemical nomenclature (e.g. in a user interface, word document, text mining) and has software for searching databases in the works.

What I want to highlight here is a bizarre way he found to speed up a Python script (via Andrew Dalke) by turning it into a function. If you go to his page on PPAccelerator, which is all about a potential product that speeds up Pipeline Pilot scripts (by up to 37 times if interpreted, or 1083 times if compiled), you will see timing comparisons of code for the Mandelbrot fractal written in different languages.

You will see two Python v2.5 examples, the second of which is about twice as fast. Look at the code for each. The only difference in the second case is that the entire script has been wrapped in a function (main() in this case), which is called at the end of the script. This is just plain weird! I don't think I've ever heard of this effect before. Apparently, Python optimizes the bytecode of a function but not module level code. If this is written anywhere in the docs, I certainly can't find it.

On a final note, a quick Google search brings up promise, which may be useful for exploiting such optimizations further.

Notes:

[1] The ACS don't provide any means to list Author Choice articles on their website. Supposedly Author Choice articles should receive increased exposure but the ACS seem to want to hide them.

Thursday, 1 July 2010

Silicos to donate code to Open Babel

Earlier today, Dr Hans De Winter, CSO Silicos, sent an email to the Open Babel development list announcing their intention to Open Source their Spectrophore, pharmacophore alignment, and de novo design code:
...it is our pleasure to announce that Silicos NV, a Belgian-based company providing services in the field of computational drug discovery and virtual screening, has made a strategic decision to port its own developed software under the open source domain of Open Babel following the GNU GPL.

...The reason why we have made this strategic decision to port all our software to the open source domain is that we, as management of Silicos, strongly believe in an open innovation model, and open source is just one of these factors that make open innovation possible. For Silicos as a company, we believe that by actively participating and supporting the OB community, we could create more business in the form of services than we could otherwise...

I'm quite excited about this, both about the actual code being contributed and about what this decision signifies for Open Babel. I've always believed in the idea that contributing novel algorithms to a common resource is the best way of maximising usage; you still get full credit for your work, you still get your paper, but you are going to have basically bajillions of users. The fact that a commercial company also groks the advantages is significant.

Porting the code to Open Babel is currently under way, and a formal announcement will be made with the release of Open Babel 2.3.0 in a couple of months.

Wednesday, 23 June 2010

Visualising orbitals and density with Molekel

Molekel is an open-source 3D molecular visualisation package for analysing the results of computational chemistry packages. It has been developed at the Swiss National Supercomputing Centre by Ugo Varetto (et al.?). Unlike Avogadro, it does not have facilities for setting up calculations or building structures; however, at least for what I want to do, it has the edge in visualising orbitals and density. So, my curent workflow is to set up Gaussian calculations with Avogadro, and then analyse them with Molekel.

One interesting aspect of Molekel is that the electron density (and orbitals, etc.) are calculated on the fly by Molekel rather than extracted from a cube file. This makes the program much more capable and completely avoids the need for cube files. On the other hand, it is not possible to save the volumetric information generated by Molekel, so there is no way to sanity check the accuracy against a Gaussian cube (e.g. by subtracting them with cubman, and then visualising the results).

It took me a little while to figure out a workflow for using Molekel successfully on Windows with Gaussian 09 log files from a Linux server. Here's how it goes:

  1. Run a single point calculation with POP=(FULL, ESP) and GFOLDPRINT. I also use IOP(3/36=-1) to reduce the file size. The current release of Molekel will not be able to colour surfaces with the electrostatic potential unless the ESP option is specified (this information is courtesy of src/old/readgauss.cpp around line 1043).
  2. Convert the log file to Gaussian03 format using the bash script available here. (I hope they will fix this in the next version of Molekel.)
  3. Convert to dos format with unix2dos. If you don't do this, you will get a segfault from Molekel after opening the file. (They should fix this.)
  4. scp the file over to your Windows machine. (It would be nice to be able to open the file directly on the server using ssh; maybe this is planned for the future?)
  5. Start Molekel, File, Open, Choose "G03", then the filename and "Open". If you don't choose G03 and instead use "All files", it will fail horribly.
  6. Under Display, 3D View Properties, change Samples to "10" to add reasonable anti-aliasing. This also affects images saved to disk so it's worth doing as the difference is quite noticeable.
  7. Also under Display, Set Background to white, and turn off the bounding box and the axes. (There is a bug if you leave the axes on and choose scaling > 1 when saving an image - the axes are repeated several times.)

In practice, I carried out steps (2) and (3) using Cygwin on Windows, but it would be easier to do this on the Linux server. (As a side issue, I note that only the File, Edit, Interaction and Help menu are accessible through keyboard shortcuts - hopefully this will be fixed in a future release.)

To actually draw the orbitals and so forth you go to Surfaces/Electron Density, but see the video tutorials on the Molekel website for more information. One thing that might save you some time is to generate all of the orbital isosurfaces you want first, and then go to File/Save Orbital Pictures and choose a folder - this automatically saves all of the orbital images one after the other with sensible names.

As a final point, if you have a better graphics card than I do, you will be able to apply some really impressive shading effects using the GLSL shaders under Display/Shaders. Again see the video tutorials on the Molekel website for a demo.

Tuesday, 15 June 2010

A non-random method to improve your QSAR results - works every time!

I was going to say this was a novel method, but unfortunately it isn't. The idea of splitting a data set into training and test sets non-randomly is one that is very appealing, seems quite reasonable at first, and leads to great results. And those results are completely misleading.

The safest procedure when doing the two-third/one-third split (or whatever) of a dataset into training and test sets is to choose the split randomly. As soon as you do anything else, the performance of your results on the test set will not be related to its real-life predictive performance.

Now and then a paper comes out where the training set is chosen to be a diverse set (whether by a Kennard-Stone type procedure, gridding the points, or initial clustering). At first this seems quite reasonable: you've made sure that you have chosen points that span the entire space of your dataset. In actual fact, what you've just done is to ensure that all of your test set points are close to a point in your training set. This means that the predictions on the test set are now woefully optimistic and unrepresentative of predictions on a true test set (which probably won't have the courtesy to be close to points in your training set, nor be distributed evenly across the whole space).

Here's another way of thinking about it. Let's imagine that our predictive model is meant to work on a particular chemical space of molecules (the domain of applicability or so). These molecules have a particular distribution of descriptor variables (or whatever). And both the training and test sets are supposed to be representative samples of this distribution. However, once you use a non-random method to split into training and test sets, both the training and test sets become less and less representative of the population and hence you will have little idea of the real-life predictive ability of your model.

I've never seen this idea written down anywhere, so I'd be interested to know whether anyone thinks there is justification for choosing a non-random training set in certain circumstances. My own advice though is to keep it real and keep it random.

Image credit: Arenamontanus