I have a hard time accepting that this is true for any but the simplest of molecules. Takes caffeine or Diazepam as more realistic examples. These have double bonds, which are drawn offset from the center-to-center line, and use elements besides carbon, which need either labels or CPK color assignments.

Even in the case shown here, benzene should be drawn with double bonds for correct Kekule interpretation, or with one of several ways to denote aromatic bonds. However, there are fields like macromolecular structure visualization where bond type information is often omitted, so this is not critical. But drawing cyclohexane would be difficult because of the non-planar hydrogens.

There are any number of tools for making eye-catching images. These include programs that will render the atoms and bonds using more complex materials, and including shading effects, fog effects, and multiple light sources. I think it would be better to leave this PP example in the "neat though very limited applicability" category.

I saw a PowerPoint slide presentation recently demonstrating how electrons form different kind of bonds in molecules, with the orbits of each electron modeled by hand in powerpoint and animated...including custom paths for the valence electrons.

Among all the atoms in the molecule, there were dozens of electrons whipping around the slide in perfect loops, it was kind of breathtaking to think somebody spent likely weeks putting that slide together.

I always wondered why presentation packages like PowerPoint and Keynote do not expose a scripting API to allow one to programmatically keyframe animations and such. That would make these sorts of effects almost trivial to achieve.

It seems a bit odd to spend that much time animating individual electrons flying about. From QM we know that such classical models completely and utterly fail to reproduce almost all important bonding behavior (certainly anything covalent). Don't get me wrong, the schematic bonding formalism employed by chemists is very useful and students need to learn it even before they learn the QM behind it, but showing electrons flying around a ppt slide departs from the schematic formalism towards a conceptual destination which is plausible but incorrect and lies in the exact opposite direction from our current best model of physical reality.

Of course, the instructor may have been ridiculing the model or using it as a bookkeeping mechanism for a more advanced class, but if this slide was made for an intro chem course it sounds like a complete pedagogical mess. A textbook example (hopefully not literally) of doing something only because you can and making things worse in the process :(

Readers interested in chemistry modeling software solutions may want to go beyond the capabilities of PowerPoint to a specialized program for chemistry modeling. The program I know best, Bitwixt,[1] has been refined over more than a decade and is a very interesting educational tool.

In minute 23 he talks about computing the second derivative of the force fields, and how complex it is. Thing is, my co-worker did that manually when he wrote the original NAMD implementation. (NAMD is a molecular dynamic program.) So it's not something that's all that hard to compute. It's just tedious. (And his code is 10% slower than the hand-written code, so he knows that people do this sort of thing manually.)

While it's useful to have automatic code generators if you want to add new force fields often, we just don't do it all that often, because parameterizing the force field is the hard problem, not computing the second derivative.

At 31:25 he says that SciPy is only really possible because of Boost.Python. This isn't true. I just downloaded scipy-0.16.0b2 and verified that it does not use Boost.Python. ("ag -i BOOST_PYTHON_MODULE" finds no matches.)

At 49:30 he talks about a technique that sounds like pharmacophore models, which have been around since at least the 1990s. There are tools that will build molecules to fit pharmacophore models.

What I didn't see was anything about dealing with waters, and counter-ions, toxicity, or AMDE (absorption, distribution, metabolism, and excretion) issues.

I didn't hear anything which required multiple years of tool building ("yak shaving") to get to what he wanted. Every technique he mentioned is something that people have been doing already, in C/C++/Python.

scipy uses cython (previously swig). It is correct that its performance depends on C and Fortran code (but you knew that).

Are you sure your coworker found the derivates for the force field? They were already published when VMD was written.

I think you're trying to quibble with some of his minor points. Schaf's quite aware of water and counterions (we used to work in the same room at UCSF when he was writing AMBER's LEaP tool that adds water and counterions to molecules).

The speaker said that SciPy uses Boost Python. My comment here was that it does not. I said nothing about SciPy's performance.

I didn't say that my co-worker was the first to compute the derivatives. I said that it wasn't that complex of a task. Mark Nelson worked out by hand the second derivatives for the force fields and implemented them in NAMD (note: NAMD is not VMD). He also checked it against a couple of other implementations, including the one in XPLOR. I think he also checked against PMD and YAMD, and I believe he noticed that the PMD implementation was copied from XPLOR.

It can make sense to develop new tooling to generate code automatically. The result might be faster than manual code, but as we heard, the auto-generated code is currently 10% slower than manual code. Or it might make sense when developing many different types of force fields, like what Konrad Hinsen does in ScientificPython (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.... ). However, I heard nothing about developing new force fields, and in any case, parameterization is the limiting factor, not computing the second derivatives.

My 'quibbles' are two-fold. The major one is that I heard or read 30+ years of history on how molecular modeling can be used to design solutions to real-world problems. The 1980s thought that it would be a CAD problem (which it wasn't). The late 1990s thought it was a simple matter of nanotech, with all sorts of designs for nifty diamond-based structures with no real-world hope. We've had special purpose programming languages for molecular modeling, custom computers with specialized networks, custom designed chips, GPU-based implementations, and more.

There's no evidence that the limitation is in the tooling, which is a major part of the speaker's thesis.

The minor one is that if someone makes minor mistakes that end up placing the speaker in a brighter light, and says them with confidence, then I believe it's reasonable to discount more the major points said with confidence which have less evidence, and which also place the speaker in a brighter light. What you see as quibbles for minor points I see as a way to judge how strongly the speaker is willing to trust personal beliefs over evidence and proof. (Yes, those personal beliefs might be right, but that's my previous point.)

The result is good, but it seems like more effort than necessary and using drawing objects in Office is always a recipe for compatibility problems if you use any other program (e.g. Libreoffice or the the web version of Office).

Agreed, the time invested to learn how to make objects such as shown in Powerpoint would be better spent learning to use Illustrator or Gimp. The results would be much more useable across different media as well.

Yes, there are much better software suites than generic ones for drawing and manipulating molecules, including dynamic simulations, etc.

If someone is using Powerpoint to draw molecules they're not likely a professional chemist or biochemist. So the amount of time spent learning something like Illustrator would apply to whatever else they do as well.