Putting the Squeeze on 'Em

As I went to get some shampoo in the shower earlier this week, I had a familiar experience: The bottle was running low, so we stored it upside down. Sometimes the air trapped inside is at a higher pressure than the surrounding air, which causes shampoo to be forced out by the extra pressure. Normally, I'd stop this by squeezing the bottle in a way to suck the shampoo back in, but the brand we have right now uses bottles with a circular cross-section, so that didn't work. It did get me thinking about how the right geometry lets me control the pressure inside the bottle.

Most of the shampoo bottles I've used in the past have had a cross-section that's roughly elliptical, which have an area of

where a and b are the half-width, and half-height. If I squeeze on the longer axis, I can shrink a and expand b, which changes the area:

We need to choose a precise relationship between a and b – I decided the ellipse should have a constant perimeter. That can be calculated with

Unfortunately, there's no closed-form solution for this, so instead I set up a Python script to calculate it. The pressure in the bottle will be inversely proportional to the volume, which for any cylindrical shape is just the area times the height, so we can write

where p and A are the initial pressure and area. Now, given a change in a, we can find the value of b that keeps the perimeter constant, then get the area, and then the change in pressure. Using a fixed value of 1 for the initial b size, we can try a couple different values for the initial a size to see how they react to squeezing:

Increasing the width by squeezing along the smaller axis always increases the pressure, which makes the shampoo come out of the bottle. The wider the large axis is, the more difference squeezing it makes, but if a = b = 1 like the bottles we were finishing, then any amount of squeezing will increase the pressure, resulting in too much shampoo!

A Breath of Fresh Vacuum

This past week was LISACon 8, a meeting of the LISA Consortium, similar to the LIGO meetings I've attended in the past. One of the presenters showed this daVinci-esque drawing of the LISA constellation:

ESA

A couple weeks ago, I talked about how I was working on a model of the rotation of the LISA satellites. Nominally, the satellites form an equilateral triangle, with 60° angles, but over the course of a year's orbit, those angles "breathe", getting wider and narrower as the spacecraft move along their orbits. That means that we need to change the angles the lasers point, so they can hit the distant sensors.

The laser beams are sent and received by Movable Optical Sub-Assemblies (MOSAs), the tubes in the picture above. We need to rotate those MOSAs to track the other satellites, but there's a problem: Angular momentum is conserved. Usually, we can count on the Earth to absorb extra angular momentum, but that's not possible in orbit. When we turn one of the MOSA, the spacecraft will turn under it. We can figure out how much using Newton's laws:

This says that the sum of the torques on each MOSA and the body of the spacecraft have to cancel out – "Every action has an equal and opposite reaction." We can use another of Newton's laws to express those torques in terms of the angular acceleration:

Here, the Is are the rotational inertia of the MOSAs and the spacecraft. The accelerations are measured in the inertial frame where all three bodies are rotating, but the MOSAs move within a range on the spacecraft, so we really want relative accelerations. We can get this by regrouping things:

We can make a bare-bones model by imagining two rods rotating in a solid disk to get I_M and I_S, then integrate to get the angles:

where m_S and m_M are the masses of the spacecraft and each MOSA, and φ1 and 2 are the angles of the MOSA relative to the spacecraft.

The Summer of Heat & the Winter of Desiccation

Thanksgiving put baking on my mind, and I started thinking about a post I wrote several years ago about baking a cake in different sized pans. I had been concerned in that post that I didn't take into account the evaporation of water from the cake, which would change the way it heated. This week though, I thought of a way to account for that, and decided to follow up on my previous post (and continue the French Revolution theme).

To recap, my mother Sally was baking a cake, but her pan was smaller than the recipe called for. That meant the cake would be thicker, and she wondered how that would change the cooking time. The key to figuring out how temperature changes spread through an object is the heat equation:

This says that the change in temperature at a point is proportional to the variation in temperature at the surrounding points. I mentioned last time that it was the proportionality constant, α, that depended on the moisture content of the cake batter. I realized that we could account for a changing amount of water by varying α according to

where m is the mass of water and of other ingredients in the cake, and α the individual diffusivities. I was surprised to find that a group of food engineers (!) had actually measured the thermal diffusivity of flour. Taking a sheet cake recipe as an example, we can approximate the amount of liquid (~water) and the amount of flour to get the effective α.

It still remains to determine how the amount of water changes over time. I looked into a couple ways to tackle this, and I'm not sure how accurate my technique is, but it made the most sense to me: The particles of a substance at a certain temperature have a statistical distribution of energies. For ideal gases, there's the Maxwell-Boltzmann distribution, and even though that's not a great model for liquid water we'll go for it. It takes a certain amount of energy for water to evaporate, called the heat of vaporization. If we assume that all the molecules with this much energy do leave the solution, we can keep track of the current number of water molecules still in the cake. Taking out those high-energy particles will also cool the cake, so we can figure out the temperature change with the heat capacity.

I updated the previous code to include these new modifications. Once again, we start off by measuring the temperature after a given amount of time using the wider pan:

In contrast to the previous results, the center temperature goes well above water's boiling point! We can also look at how the amount of water changes over time:

I was surprised to see that the center of the cake experiences almost no loss in water. Even the edges don't lose much – The color scale varies from 50 to 60%. To check what effect the loss of water has, I reran the test with the same α calculated above, but left the amount of water constant. The results are almost identical:

As in the previous post, we can use that central temperature as a target for the narrower pan, and find the cook time:

As before, we get about 70 minutes, suggesting the water content is not as significant as I imagined. A big part of physics is figuring out what you can approximate, and what you can't – which results are "good enough". It seems cakes can be quite forgiving when it comes to baking precision!

Sowing Division

We have several recipes that make 6 servings, and I always have a hard time dividing them equally. It seems I have an easier time splitting things in 2 rather than 3 or other divisions – I assumed this was a human tendency, but I can't turn up anything from searches. While cutting up a casserole one evening, I started thinking about how after cutting 1/3, the next cut would be half of 2/3. Instead of making that cut, I could mark the half and then flip the relation: I have a new 1/3, and I can split the remaining 2/3 in half.

We can put this idea in more mathematical terms: I want to place points a and b on a line of length 1 so that a = 1/3 and b = 2/3, but I can only put them at halfway points. If we start with a0, then b0 goes at (1 + a0)/2. If we keep going back and forth, then

Writing out the first few terms of the sequence for a lets us identify it:

The term in the parentheses is a geometric series, which can be replaced with a simple form. After some rearranging, we get

I realized this technique could be applied to any number of cuts by adjusting each to the center of the two neighboring cuts. Finding an expression for the general case is "left as an exercise to the reader" (textbook cop-out) – I just tossed the algorithm into Python. The main thing I was interested in was how long it takes to get an accurate estimate of the divisions, so I plotted the RMS error at each step:

Each line represents a different number of cuts. Notice that the y scale is logarithmic, meaning these straight lines actually represent exponential decreases. The line for 2 cuts into 3 pieces drops so quickly, it appears to run into some precision error. As the number of cuts increases though, the error is much more difficult to reduce. To get a more concrete handle on this plot, I also made an animation of the cuts as we make iterations:

For the first step, the divisions are evenly distributed at the two endpoints, which is really a worst case scenario. However, we can see how quickly the 2 cuts on the first line settle in place. Moving up the plot, each line takes a little longer to stabilize.

I'm not sure my serving-precision needs are high enough to require actually using this technique, but it was interesting to think through!

Eule Slick

A couple months ago, I talked about the LIGO work I'm doing here in Florida, but I'm also working on the LISA project, a gravitational wave detector in space. The detector consists of 3 spacecraft that orbit the Sun trailing slightly behind the Earth:

Wikipedia

Recently I've been developing a simulation of the LISA spacecraft, specifically their orientation to face each other. This gets into a part of Physics that I don't have a lot of experience with: rigid-body dynamics.

Most of the time, physicist can get away with considering things to be points or spheres, but things get more complicated with asymmetrical objects. Suppose we have a box that we want to rotate around two axes, x and y. Depending on which we do first, we get different results:

To get around this ambiguity, the mathematician Leonhard Euler (pronounced "oiler") realized you can specify the orientation of a 3D object by defining 3 rotations from a principle set of axes:

Wikipedia

I won't get into the details of how the angles are defined, but the result explains some really interesting effects. Here's a video recorded by a NASA astronaut aboard the space station of a "T-handle" spinning:

That strange tumbling behavior is explained by Euler's rotation equations:

where ω is the angular velocity, and τ is the torque applied. The I is the moment of inertia tensor, which requires some explanation: Simply put, it's the rotational equivalent of mass, which quantifies how a torque relates to an angular acceleration. What complicates things is that I depends on your choice of axes. It's a simple diagonal matrix in the frame where the T-handle is fixed, but that frame rotates. The fact we're working in a rotating frame results in the second term in the equation above.

Here's where the Euler angles come in: The differential equation above tells us how the angular velocity is changing, but we're interested in how the orientation of the handle changes. We need to relate the angular velocity to the change in the Euler angles, and include those in our integration. Putting everything together, we can simulate how the handle reacts to an initial rotation.

First with the spin perfectly aligned, nothing too interesting happens:

If we introduce just a 2% offset in the angle though...

we see precisely the sort of flip from the video! I've said it before here, but this is why I love Physics: With just a few relatively simple equations, you can explain even the weirder parts of reality.

Learn All That is Learnable

[Title from Star Trek: The Motion Picture, V'GER's mission.]

Earlier this week, the Voyager 2 spacecraft broke an 8-month silence to check in with NASA researchers. This is one of the most distant space probes from Earth, currently about 11.6 billion miles away. It was originally launched in 1977, with the primary goal of observing Neptune and Uranus. To get to those planets in 1989, it was given enough velocity to leave the solar system entirely, which it did 2 years ago. The antennas that communicate with Voyager, called the NASA Deep Space Network, were under maintenance for the past 8 months, preventing contact.

After seeing the news article about the renewed contact, I started reading more about the probes, and how they achieved their Sun-escaping speed. They key lies in the idea of a gravity assist, where by flying by a planet in the right way, an object can get a boost of speed:

Wikipedia
   Voyager 2 ·   Earth ·   Jupiter ·   Saturn ·   Uranus ·   Neptune ·   Sun

The principle at work in a gravity assist is actually something usually taught in intro Physics: an elastic collision. This is when two (or more) objects interact in a way that conserves both energy and momentum. An everyday example is a rubber ball that bounces to its original height when dropped. The energy and momentum of an object are given by

where m is the mass and v is the velocity. Conserving these quantities means that before and after the collision, the sums of each one for all the objects involved stays the same. To simplify things, we can consider the case in one dimension: Initially the probe and planet are moving toward each other, the probe slingshots around the planet, and leaves in the opposite direction it came. Then we can use the elastic collision equations to get

where capital variables are for the planet, lowercase for the probe, and i and f for initial and final. Since planets are generally a lot bigger than space probes (though maybe not in the case of the source of this post's title), we can Taylor expand around m/M ≪ 1 to get

Jupiter's mean orbital velocity is about 13.1 km/s, or about 30,000 mph, and we could get double that! Unfortunately, the angles typically don't work out that way, as you can see in the animation above.

I feel that any discussion of the Voyager Spacecraft has to include the hope that went into creating them, and to that end, I want to end this post with a picture of one of the Golden Disks. Each of the spacecraft was loaded with a message to the stars about Earth and its people. We looked for a way to represent ourselves to the cosmos, and found what was best in us.

Pitching Forward

In their house in Ashfield, my parents have a 500-foot well that delivers their water. Growing up drinking that delicious water has spoiled me for most municipal water supplies, including the one here in Gainesville. To appease my picky palate, we got a filter:

The tap water goes in the reservoir at the top, then drains down through the filter to the bottom. It's possible to pour filtered water while some is still in the top area, and it made me wonder how the pitcher's center of mass changes as it tips forward, and as the water drains through.

The first problem is to find the shape of the water when the pitcher is tipped at an angle. The surface of the water will stay horizontal, so if we imagine tipping to an angle θ, we can instead imagine the pitcher flat, with the water at the angle:

Looking from the top, the pitcher is approximately an ellipse:

We're looking for the center of mass of the water, which is given by

where M is the total mass, and ρ is the mass density. This is essentially the weighted average of the position of each bit of water. Since water has uniform density, we can replace ρ and M with the total volume. Figuring out the limits of integration is a bit tricky: We can imagine moving in the x direction in the diagram above (left to right) adding up squares of water. The widths will be

and the heights will be

This makes the integral pretty ugly, so I threw it into Mathematica for an answer:

That's just for one of the water reservoirs; to get the CM for both, we weight the positions by the amount of mass in each. Since we're interested in tipping the pitcher forward, we can measure the angle of the CM from the front edge:

Remember though that we're also tipping forward by θ, so for the tipping point, we're looking for θ + φ > 90°. I put together some Python code to find the CoM angle for various tipping angles and points in the filtering process:

I find it really interesting that under this model, the 90° tipping point stays nearly constant. However, this fails to account for when there is not enough water to cover the bottom of either reservoir. From experience, I certainly don't feel the pitcher falling forward as early as 9 or 10 degrees. I tried to account for that in the integral, but the lack of symmetry makes it too difficult for Mathematica to handle. Even with that missing piece, an interesting system to analyze!

Racking my Brains

This week I got another question from my brother Nate. He's looking for a way to hang laundry to dry, and he found designs like this one appealing:

George & Willy

He figured it was simple enough that he could build one himself. He wondered though about the height of the triangles. He's hoping to hang the rack high enough that they can walk under it without getting pants in their faces, so the triangles should be as short as possible. Unfortunately, that makes it easier for the rack to tip if the clothes aren't perfectly balanced, which will bring some of the clothes lower. His question then was this: How do I choose the height so I have the most headroom?

As I started to diagram this out, I realized it was a much more complicated system than I first imagined. Looking at it from the side,

Here we have one side of the rack with more weight than the other, which makes the whole thing tilt by an angle ɸ. When we're dealing with rotation, we want torques in place of forces:

The X here is a cross product, which depends on the angle between r and F. What's really interesting is that since the weight always points down, this angle changes as the rack tips. For the right side of the rack, the torque is

After a bunch of simplification this becomes

and similarly for the left side,

We're interested in where the rack settles, so we can add these torques together and set the result to zero.

Now we have the angle, but what we really want is how low the rack gets. This is given by

Once again applying a bunch of trig identities gives

Trying to combine this with the equation for ɸ makes things even uglier than they already are, so let's plug in some values instead. If we imagine hanging 1 pound on one side of the rack, and 0.8 pounds on the other, we can try several heights and widths to find the shape of the depth function:

The minima seemed linear, so I threw the messy equations at Mathematica (thanks, UF site license!) and got something reasonably simple:

If you weigh some wet clothes, you can get some values for F1 and F2, plug them in here, and get the relationship you need for the width and height.

When I was talking to Nate about this question, he mentioned describing my blog to a friend. He noted that some of my posts involve long lists of complicated equations that end with me saying "Huh, that didn't work." Well, to Nate (and that friend if they're reading) I say not all my posts! Some involve long lists of complicated equations that end with a general equation for designing a laundry rack! Well, one.