Sound physical inference from an illusory premise

Don’t let this animation
fool you about the physics!
By now, many scientists have seen videos of molecular-scale mechanical devices like the one shown here, and I have no way to know how many have concluded that the devices are a lot of rubbish (and have perhaps formulated an unfortunate corollary regarding your author). The reasons for this conclusion would seem clear and compelling to someone new to the topic, but because I was too close to it, I saw no problem. Familiarity with the actual dynamics of these devices kept me from recognizing that what the videos seem to show is, in one crucial respect, utterly unlike reality.
If only all these videos could be recalled and upgraded in the way shown below…
First, I should note that the standard videos have considerable merit. They show the output of realistic molecular dynamics simulations based on conventional molecular mechanics force fields. Further, the behavior of most of the mechanical devices shown is remarkably insensitive to perturbing forces, and hence is insensitive to force-field inaccuracies. The simulations can be used to assess engineering parameters such as coupling stiffnesses, static friction, and dynamic drag. They also show the amplitude of thermal motion correctly — but then comes the break between appearance and reality.
The small, jittery animation at the top shows a shaft rotating in a sleeve. The friction in this device would in reality be quite low, enabling the device serve as good bearing. But compare the motion of the shaft and the (apparent) vibrational motions of the atoms: Although the rotation-induced speed of the shaft surface is substantially lower than the (apparent) vibrational speeds of the atoms, the two speeds are (apparently) comparable.
It’s easy to see that thermal motions and shaft motions would be strongly coupled, if this were true. The motion of the shaft would be fast enough to pump in vibrational energy, and this vibrational energy would quickly dissipate as heat. Relative to the (apparent) thermal speeds, the shaft surface speed is much too high, far outside the operating limits for a sensible system design. (For perspective, the implied rotational frequency would be on the rough order of 100 GHz; dissipation scales as the square of the speed, which might typically be 1/1000 of this.)
In short, the videos seem to show devices in which the drag of sliding friction would be enormous, and the rate of heating would be astronomical. This would preclude nanosystems with reasonably efficient molecular machinery, manufacturing, etc.
So what’s wrong with this conclusion? Well, one hint is that all the atomic vibrations are at the same frequency — the frame rate of the video. What the video shows isn’t vibrational motion, or the blur that one would see at this speed, but instead a stroboscopic sample of atomic positions at what are, in the relevant sense, very long intervals. If the frame rate were fast enough to follow the thermal vibrations, the shaft rotation would be almost imperceptible. And if one wanted to show realistic motion blur, well, sorry, but there’s no software that will do the required rendering and image combination automatically, starting with a molecular dynamics trajectory file, and so it doesn’t get done. (Would someone fix this, please?)
To the best of my knowledge, only one video in existence shows all this, and (with thanks to Will Ware for a lot of work), here it is:
(Erratum: the simulated temperature is somewhat too low; at 300 K, motion amplitudes would be about 20% larger than shown.)
J. Storrs Hall has prepared a video that shows thermal motion properly and directly, but this makes a shaft rotating at 1 GHz appear glacially slow, which is why videos showing machines haven’t ordinarily been done this way. If you watch, you’ll eventually see that the rotation is clockwise.
Please note that the ability to make molecular structures of the sort shown here is far down the likely roadmap. Previous posts have said more about where we are today and directions forward.




{ 3 trackbacks }
{ 8 comments }
Vladimir Golovin 02.10.09 at 12:11 pm UTC
there’s no software that will do the required rendering and image combination automatically, starting with a molecular dynamics trajectory file, and so it doesn’t get done. (Would someone fix this, please?)
Eric, my 3DS Max skills are a little rusty (it’s been 10 years since I last used Max to actually earn money), but I’m pretty sure that all functionality you need is already built into Max.
There is a function called “Object motion blur” in Max, which actually does the temporal anti-aliasing of the animation by sampling the image multiple times per frame — basically it composes the final animation frame by rendering multiple frames at fractional time points and averaging the results.
Here’s the link to the Max help page on Motion blur:
http://www.kxcad.net/autodesk/3ds_max/Autodesk_3ds_Max_9_Reference/index.htm
The devil is, as usual, in the details, so to achieve the accuracy we desire we’ll need to pay close attention to the motion blur parameters — as opposed by just turning it on. Here’s what seems to be important:
1. Always use “Object” motion blur, not “Image” motion blur.
2. If the Scanline renderer is used, make sure to set Duration to 1, Bias to 0.5 and Frames to the actual number of averaged sub-frames you want to integrate into each final frame. To speed the rendering up, turn on “Disable Filtering” and “Disable Antialiasing”. Here’s the help page for the Scanline motion blur: http://www.kxcad.net/autodesk/3ds_max/Autodesk_3ds_Max_9_Reference/index.htm
3. For the Mental Ray renderer is used, the help looks a bit messy, and, frankly, the Scanline renderer will do just fine here — no need to spend extra hours (or perhaps days) rendering a bunch of blurred spheres in Mental Ray. But here’s the help anyway — pay attention to Shutter Duration and Offset: http://www.kxcad.net/autodesk/3ds_max/Autodesk_3ds_Max_9_Reference/camera_effects_rollout_mental_ray_renderer.html
Regarding the molecular dynamics trajectory files, I don’t see any problems as well. I assume that the trajectory is supplied as a list of 3D positions at regular time intervals (no splines / curved segments). If so, it can simply be imported into Max as a spline.
Then we can set the animation duration to our desired time in seconds, assign the trajectories to molecules as paths, calculate how many motion blur subframes do we need, configure the Motion Blur, and render the stuff.
Vladimir Golovin 02.10.09 at 2:20 pm UTC
>>> I assume that the trajectory is supplied as a list of 3D positions at regular time intervals
Uhg, looks like I missed something — the output of a molecular dynamics simulator should also include the information about the orientation (rotation) of the molecules, in addition to their trajectories. This makes the Max animation of molecule rotation more complicated.
If the guys who do the visualization have a C++ programmer and the Max SDK handy, they could write a Max controller plugin that could parse the MD sim trajectory file and translate it into positions and rotations of Max objects. There is also a less hardcore alternative — 3DS Max 2009 supports .NET scripting.
However, all the above does not invalidate the motion blur suggestions — as long as their animation reflects molecule movement, rotation and timing correctly, adding Motion Blur is trivial.
Eric Drexler 02.10.09 at 10:04 pm UTC
Thanks for examining this question. To clarify the problem, the output of a dynamics simulation is a series of sets of coordinates and atom identifiers, and typical images are either overlapping spheres (physically more realistic) or separate spheres that overlap cylinders representing bonds (showing the structure better). Doing just the first would be enough to be very valuable.
There are, of course, multiple rendering modes in use, but it is important to include shadowing of one sphere by another to show the overall shape of the object. Most of the good-quality images are done by ray tracing, but for multi-frame averaged images, there would be no need for anti-aliasing, which would speed things up a bit. Another approach, however, is implemented in Qutemol. This was developed specifically for molecular visualization, and handles shadowing differently and very effectively. I prefer it.
Images of more of those super-advanced, future-nanofabrication-based molecular nanomachines are displayed in a Nanorex gallery, with renderings in both styles. (Another gallery shows structures that can be made today, but motion-blurred dynamics isn’t a useful way to show their functional behavior.)
Will Ware 02.11.09 at 2:06 pm UTC
A better approach to motion blur than I used above would be to use a blurry ellipsoid like the probability clouds in quantum textbooks. One could take several samples of an atom’s position during one movie frame and average them with principal component analysis to get the orientation and size of the ellipsoid. In the animation above, I rendered each stroboscopic subframe individually and averaged the images together. Using ellipsoids would save considerable computation and would be visually more accurate. I’m pretty sure POV-Ray allows objects to be rendered with varying levels of transparency, so one could construct a blurry ellipsoid out of concentric “sharp” ellipsoids of decreasing opacity.
Vladimir Golovin 02.11.09 at 4:38 pm UTC
Will — yes, hit-testing rays against ellipsoids is very cheap, but unfortunately this will work only in raytracers that explicitly support them (as far as I know, modern renderers like Mental Ray and VRay don’t expose their support of procedural ellipsoids — they must be tessellated into polygons before rendering).
POV-Ray does support procedural spheres, but it cannot render Ambient Occlusion and contours, which are essential to create the Qutemol look that Eric prefers for molecular visualizations.
Also, procedural ellipsoids aren’t supported by GPUs — they also accept polygons only, so if we use a GPU-accelerated renderer ellipsoids won’t help. Yes, there are GPU-based raytracers like the Intel’s one, and they must support procedural ellipsoids, but I’m not sure about their availability (both commercial or open-source).
Regarding transparency: yes, of course POV-Ray does support it, but my hunch is that we won’t gain much compared to the proper motion blur / averaging stroboscopic frames. Also, I expect that transparency will make proper shadowing (let alone Ambient Occlusion) impossible or very difficult.
By the way, just found a command-line tool that can average specified images together (scroll to the bottom):
http://www.imagemagick.org/Usage/layers/
Will Ware 02.12.09 at 3:57 pm UTC
Maybe then a ray-tracer is not the best tool to use. It’s overkill to worry about getting the shadows in the right places, and whether the reflections and refractions through/around a carbon atom are correct, so a raytracer like POV-Ray really attacks the wrong problems. Way back when I wrote some much simpler code for rendering molecules, and it could easily be modified to handle ellipsoids. It’s basically a Z buffer, so transparency would be a bit messy, each pixel requiring (I think) a tree structure of the surfaces, terminating a branch either when it hits something opaque or when any remaining transparency gets too dim to matter.
Above, I suggested PCA as a good way to determine positions and orientations for ellipsoids. Having since taken a little time to look at what PCA does, I think that too is probably overkill. Averaging a few products of deviations should suffice to construct the ellipsoid for each atom.
I’ll give this some thought, and see if I can find time to make some tweaks in my old code.
Will Ware 02.17.09 at 6:46 pm UTC
Python code for ellipsoids is here. It turns out the math does look like PCA after all, though simplified a bit. Regrettably Google Groups reformatted my code in spots, hopefully the line foldings are obvious. Assuming I’m allowed to use an HTML “img” tag, an example appears below, with major and minor ellipse axes shown in red and green for a 2D case.
Will Ware 02.17.09 at 6:47 pm UTC
No joy with “img” tag, but the image is here.
Comments on this entry are closed.