Imagine a tinkertoy, only the sticks are replaced by springs, and the joints between the ends of the springs are hinged, so that the springs connecting to a joint can do so at any angle freely. Start with a structure where at least some of the springs are under stress--compressed or stretched compared to the length they like to be--and the forces aren't balanced. We want to know what shape the tinkertoy will take when all the forces have settled out.

This is the same problem engineers need to solve when designing bridges or car frames, to see how they bend and flex under different loads. In the finite element method, you replace any continuous piece of material with a mesh of abstract tinkertoys, then apply imaginary loads, solve some equations, and see how the mesh reacts.

Most applications of the finite element method involve objects that don't bend all that much from where they started. But my interest in simulating growing plants got me onto a sidetrack: sometimes plants (imagine a fiddlehead fern) grow curly shapes that wind or unwind. The problem with this is that some of the parts of the plant can rotate through large angles, and this is a weakness of the finite element method, called "geometric nonlinearity."

The problem set up with this applet (and the one that follows) is this: imagine a ladder made out of springs. But the springs on one side of the ladder are half as long as those on the other side. So the ladder wants to have a curled-up shape. In these simulations we start with the ladder held straight, then let it go to see it curl up.

The first applet, above, is a mechanical simulation. The forces caused by the springs are calculated, and then the joints between the springs are accellerated according to those forces. Drag is applied to damp out oscillations. The applet shows some bugs in a naive version of this approach. One is that some of the ladder rungs flip over from whiplash and develop "kinks". Also, when springs get compressed to nearly zero length, they act erratically, so that between two timesteps of the simulation, the forces point in wildly different directions. This causes the twitchy behavior. It's just a fluke of the setup of this particular example that the twitches "work themselves out"--the program isn't written to do that on purpose. In other examples I tried, twitching didn't happen at all, or went on forever, or got so bad it caused arithmetic overflows and crashed the applet.

To start the applet over, scroll to the top of the page and click the reload button in your browser. When the tinkertoy above has settled down, go on to the second.