This is a summary of my blog post. It will begin with an introduction. After this, I will present the meat of it. I will then surprise you by discussing this. Finally, guess what, I will end with a pithy conclusion.
Ok - so you think I'm overdoing it. But this is exactly how summary slides in presentations now appear to me. Once I thought they were essential; now I think they take away from the presentation.
Think about it. The audience is sitting there all ready to hear about the work you're doing; they are at their most alert and ready to engage with your topic and try to understand your results. And what do you do? You show them a slide that sends them to sleep. Either it's that pro forma slide that we've all seen before, or you can't resist talking through every single aspect of the entire talk so that there's nothing to look forward to; no-one wants to hear the same talk twice.
Perhaps there's an argument to be made for a summary slide for longer talks, especially if it's the last 30 years of some professor's work and it's going to be rambling about a bit so a bit of steering could be useful. However (thankfully) the majority of talks these days are of the 25-30 minute variety and that time spent on a zero-information-content summary slide may translate into cramming the last five slides of results into 30 seconds.
Anyhoo, this is on my mind at the moment as I'm putting together a talk for the GCC in Fulda in a few weeks time. Thing is, I'm one slide short at the moment. Hmmmm...
Wednesday, 23 October 2013
Thursday, 10 October 2013
QM up for testing - The Quantum Chemistry Speed Test
Ever wondered which quantum chemistry package is fastest? No? Well you're not alone - I can't find anywhere on the webs a comparison of the speeds of different QM packages. Enter the Quantum Chemistry Speed Test...Over a series of weeks (weeks which may be spaced months or years apart depending on the ebb and flow of life), I will carry out the same calculation using a variety of packages. The calculation will be a geo-opt of a small size organic molecule on a single CPU and without any attempt to tune.
And you can play along at home. I'll be making all of the input and output files available for your viewing pleasure. Commercial software is unlikely to feature in this comparison (as I don't have access to any) but don't let that stop you. Note that for the usual reason, you should avoid publishing Gaussian timings.
The reason I'm interested in this is that it seems that the focus of many QM packages these days is towards carrying out massively-parallel super accurate calculations. But what I'd really like (and I think most users would be with me in this) is faster speeds for standard calculations. For example, in a project with Geoff Hutchison a few years back I carried out 1000s of single-CPU calculations using Gaussian on a 8-cpu per node cluster. If I had run these in parallel it would have been much slower (see Amdahl's Law) and those CPU hours would not have stretched so far.
Maybe if there were more of these speed tests, it would encourage developers to bring more performance to single-CPU calculations. Well, probably not, but it'll be fun to find out.
Image credit: Paul Townsend on Flickr
Sunday, 6 October 2013
2nd RDKit UGM gives rise to Fortran bindings
I've just been attending the 2nd RDKit User Meeting, which was organised by George Papadatos of John Overington's ChEMBL group at the EMBL-EBI. Interesting developments include the new PDB parser, MMFF94 forcefield, and Pandas integration for the IPython notebook.
Lots of great talks of which many will be available over at the github repo. I lightning-talked about creating portable applications on Windows using MinGW.
Unfortunately I didn't stick around for the third day, the hack day. Roger seems to have had fun; he used his gcc-fu to get Fortran code to compile against RDKit:
This has surely made Greg Landrum happy as he is on record as bemoaning the lack of Fortran examples in his talks. :-)
Looking forward to the next meeting already.
Lots of great talks of which many will be available over at the github repo. I lightning-talked about creating portable applications on Windows using MinGW.
Unfortunately I didn't stick around for the third day, the hack day. Roger seems to have had fun; he used his gcc-fu to get Fortran code to compile against RDKit:
This has surely made Greg Landrum happy as he is on record as bemoaning the lack of Fortran examples in his talks. :-)
...Since no talk about programming languages and computational chemistry is complete without an example of handling legacy Fortran code, this talk will be incomplete; and we can all be happy for that.
The snake that fits your brain: Python for computational chemists, COMP 82, 238th ACS
Looking forward to the next meeting already.