I've written little lately, in part because I've been busy, and in part because I've spent my leisure time enjoying the sun. But I'm working on a lot of interesting things, and I feel inspired to share.

1. Computer animators and game developers use physics-based simulations to create some incredibly convincing effects. Sometimes they resort to models that are fast and look reasonable, but are physically unrealistic; but as computers get faster, they can get more of the physics right and still run fast enough to remain on schedule.

   That's great for graphics, but what about for sound? Several professors and students at Berkeley are working on creating sounds on a computer by simulating the real physics of objects bounding off each other, or by simulating what happens when a musical instrument is played. Cynthia, a graduate student researcher in the department, has been working on simulating drums for computer sound generation. I've been helping her build some of her finite element models, which so far include only the vibration of the drumhead, but will soon include the interactions between the drum skin, the drum body, and the air inside and outside the drum. I hope to use this for the term project for my fluids class -- it's an interesting computation, it helps someone else out, and I might be second author on some related publication.

2. When you hit a drum, the sound dies away after a brief period. Why? Some of the sound energy is absorbed by the walls of the drum; some radiates out into the room, where it is absorbed by the ceiling tiles, the carpet, or the household pets; and a very little bit turns into heat energy in the air itself.

   Now, what if your drum was a bit of silicon, a small fraction of a hair's width in size, and it vibrated at around the same frequency as the carrier signal for your cell phone -- 2.4 billion times every second. The vibrations of this drum, too, will eventually die away, but the energy will be dissipated in different ways from a bongo drum. Some of the energy will escape through mechanical connections to a larger chip of silicon, to bounce around and eventually be absorbed, perhaps into the glue used to hold the chip to its packaging. And some of the energy will turn into heat inside the material itself.

   Find a rubber thick band, like the type used to hold stalks of celery together in the grocery store. Stretch it quickly between your fingers, and hold the stretched band to your lips. Can you feel a slight change in the temperature? What about when you let the rubber band relax? Rubber is a remarkable material, but in other materials, too, fast stretching and compression can cause changes in temperature, and vice versa. When an elastic material is stretched, if the stretching isn't uniform then the change in temperature will also not be uniform. Heat will flow from the warm spots to the cool spots, and in the process, some of the energy that was put into the material by stretching will be dissipated away, so that it can no longer be used to do further mechanical work. This thermoelastic damping is negligible for your bongo drum, but not for micrometer-size MEMS resonators.

   Together with researchers in the radio-frequency microsystems (RF MEMS) group and colleagues in computational mechanics, I'm involved in trying to figure out how these high-frequency resonators vibrate, and the ways in which those vibrations die out. In particular, right now I'm involved in looking at a test problem -- in a vibrating beam, how much energy is lost due to thermoelastic damping? We also hope to look soon at how much energy radiates away through the anchors by which the beam is connected to the rest of the chip.

3. Suppose you drop fine grains of sand into the water, and watch them drift downward toward the bottom. If you drop ten grains of sand together, will they fall at the same rate at which a single grain of sand would fall alone? No! Water has some viscosity, and so each of the ten grains of sand pulls its neighbors with it as it falls. Consequently, the ten grains fall faster together than they would alone -- a fact which will doubtless be astonishing to anyone with more experience in committee work than in physics. The last fluids homework involved a calculation of the descent of such a collection of slowly-falling particles.

4. If you slowly turn off a running faucet, the smoothly flowing stream will turn into a sequence of individual droplets before it finally halts completely. If you sufficiently push hard on the end of a column, eventually it will buckle to one side or the other. These are both bifurcation behaviors: sudden, qualitative changes which occur in many systems when some parameter (like the flow rate or the load in the previous two examples) exceeds some critical threshold.

   Finding the values at which such bifurcations occur is not always an easy task. There is some general-purpose software available for numerical bifurcation analysis, but many of the best software packages only work well for small problems. If the size of the problem is too large, these software packages run too slowly to be very useful. In order to extend the software that works so well for small problems to be useful for bigger problems, we use a projection method, in which we're able to examine a carefully constructed sub-problem which tells us all we need to know about the bigger problem. I have been collaborating with Mark, a math professor in Alabama, on an algorithm called continuation of invatiant subspaces, which should let us intelligently choose the sub-problems we need in order to find bifurcations both accurately and quickly.

5. I maintain a large linear algebra package called CLAPACK, which is a C translation of the venerable LAPACK library, a huge collection of Fortran 77 routines for solving a variety of problems in numerical linear algebra. It's a popular package, and I usually receive at least two or three requests each week from people who are having difficulty using the routines, or who don't understand which routines they need to solve their problems. For example, I recently had several exchanges with a gentleman who is studying the cable equation, which models neuron activity. He wanted to use LAPACK routines as part of his differential equation solver, but had trouble preparing his input in a way that made LAPACK happy. I was able to help him, and he sent an e-mail thanking me for clearing away one of the final impediments in his thesis research. I filed his thank you note where I can retrieve it easily; I like to have such notes available to comfort me when I'm forced to deal with inquiries written in broken English by those who have no grasp of what they're doing or why they're doing, but seem utterly convinced that the fault lies in some bug in LAPACK.