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
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.
Monday, 23 September 2013
Unavailable by request - Do you have to ask?
I've decided to no longer review papers where the software is "available upon request from the authors". I'm sure the world will keep turning, but I just don't want to spend time reviewing this type of software.
You see, to my mind "available from the authors on request" means "not available at some indeterminate point in the future". If they actually wanted to make it available they would have put it up on the web somewhere. Ergo, since they haven't, it means...what exactly?
I don't get it. Ok, so there's probably an innocent explanation. Maybe this is how it was done in the good ole days ("Hey, the 80s are calling. They want a copy of that software you wrote"). All I know is that I don't want to spend an hour or whatever reviewing a manuscript that describes software which may vanish into thin air.
I'd be interested to know if you have a different view on this.
Image credit: Available on request by Iain Farrell (CC-BY-ND)
You see, to my mind "available from the authors on request" means "not available at some indeterminate point in the future". If they actually wanted to make it available they would have put it up on the web somewhere. Ergo, since they haven't, it means...what exactly?
I don't get it. Ok, so there's probably an innocent explanation. Maybe this is how it was done in the good ole days ("Hey, the 80s are calling. They want a copy of that software you wrote"). All I know is that I don't want to spend an hour or whatever reviewing a manuscript that describes software which may vanish into thin air.
I'd be interested to know if you have a different view on this.
Image credit: Available on request by Iain Farrell (CC-BY-ND)
Sunday, 22 September 2013
Marketing and Scientists
Having left academia just over a year ago and joined NextMove Software, I am reminded of a comment that a postdoc made to me about why she would not like the idea of working for a software vendor: "Marketing". I once had the same idea, but after several years postdocing I realise that a big part of a scientist's job, and perhaps especially a postdoc's, is all about marketing. We can call it self-promotion or networking, if that's more palatable, but it's essentially selling oneself and one's ideas.
Let's start with the obvious stuff. Papers: they promote your ideas, and also yourself. To get the paper in, you first need to market it to the editor with the submission letter. To encourage people to read it, you need a punchy abstract and title. For further encouragement, you need some marketing: a poster, a talk, a write-up on the webs.
And yes, blogs do help. Sure, marketing is not the only reason to have a blog, but it is a positive side-effect (it's a mystery to me why more cheminformaticians don't write them). Similarly, putting talks and posters up on the web ensures a wider reach. As I've said before, more people will read it online than will ever hear you give it in person.
And then there's the pure marketing: grant applications and job applications. If like me, you are somewhat reluctant to write a page of text on how awesome you are, you'll need to overcome this handicap pretty quickly in order to fill in the various bits of grant and job applications. As for the rest of the sections, it's a fine balance between promoting your ideas as solving all of the world's problems and being scientifically realistic.
"Marketing" may not be a scientist's favourite word, but if your scientific study is buried in the literature and forgotten, it neither advances the field nor your career. So if you feel you have something worth talking about, get out there and get marketing!
Image credit: Social Media Marketing Madness Cartoon by Hubspot (CC BY-NC-SA 2.0)
Let's start with the obvious stuff. Papers: they promote your ideas, and also yourself. To get the paper in, you first need to market it to the editor with the submission letter. To encourage people to read it, you need a punchy abstract and title. For further encouragement, you need some marketing: a poster, a talk, a write-up on the webs.
And yes, blogs do help. Sure, marketing is not the only reason to have a blog, but it is a positive side-effect (it's a mystery to me why more cheminformaticians don't write them). Similarly, putting talks and posters up on the web ensures a wider reach. As I've said before, more people will read it online than will ever hear you give it in person.
And then there's the pure marketing: grant applications and job applications. If like me, you are somewhat reluctant to write a page of text on how awesome you are, you'll need to overcome this handicap pretty quickly in order to fill in the various bits of grant and job applications. As for the rest of the sections, it's a fine balance between promoting your ideas as solving all of the world's problems and being scientifically realistic.
"Marketing" may not be a scientist's favourite word, but if your scientific study is buried in the literature and forgotten, it neither advances the field nor your career. So if you feel you have something worth talking about, get out there and get marketing!
Image credit: Social Media Marketing Madness Cartoon by Hubspot (CC BY-NC-SA 2.0)
Wednesday, 11 September 2013
Poll answer: Time for Python 3?
Results are in for the Python poll: 33 are using Python 2 (of which 15 are thinking about moving to Python 3) while 8 are already on Python 3.
So still very much a Python 2 world, at least among respondents.
It'd be interesting to know what exactly is keeping people at Python 2. Inertia? Dependencies on legacy code? Deep-seated aversion to 'print' as a function?
So still very much a Python 2 world, at least among respondents.
It'd be interesting to know what exactly is keeping people at Python 2. Inertia? Dependencies on legacy code? Deep-seated aversion to 'print' as a function?
Tuesday, 3 September 2013
ASCII depiction for Accelrys Draw
At work I've been creating some plugins for Accelrys Draw, and the thought occured to me, why not enhance the colourful razor-sharp depictions generated by the good folks at Accelrys with ASCII art versions beamed direct from the 80s?
So I wrote a plugin that uses Open Babel (through its .NET dll) to generate an ASCII depiction of the displayed structure and paste it as a text object. The image below gives some idea of it in action, and since you ask, I found that an aspect ratio of 1.7 worked well for Courier New.
Unfortunately, I'm not 100% sure that I can make either the plugin or sourcecode available, and so I'm going to err on the side of caution and leave it at the screenshots.
So I wrote a plugin that uses Open Babel (through its .NET dll) to generate an ASCII depiction of the displayed structure and paste it as a text object. The image below gives some idea of it in action, and since you ask, I found that an aspect ratio of 1.7 worked well for Courier New.
Unfortunately, I'm not 100% sure that I can make either the plugin or sourcecode available, and so I'm going to err on the side of caution and leave it at the screenshots.
Subscribe to:
Posts (Atom)




