Analysis of Boeing 737 MAX 9 Door Plug Accident

I follow aviation accidents pretty closely. For as long as I can remember, I have been fascinated with air and space travel and the associated risks. I even took a flying lesson at Teterboro airport 15 years ago or so, but I never got a chance to get certified.

The latest Boeing 737 Max 9 accident1 resulted in no loss of life, but the idea of a door, even a fake door, blowing out mid-flight warrants a little analysis. Some questions come to mind: How could this happen, why it happened, under what conditions (the proximal cause), and what could have happened under slightly different conditions? First, a warning: this is not an analysis of how the defect was introduced during manufacturing and assembly; I know nothing about that. This is an analysis of the conditions under which a loose door (I will call that, even though it was technically a door plug) could separate from the fuselage.

The Facts

On January 5, 2024, at 5:00 p.m. local time, Alaska Airlines Flight 1282 took off from Portland International Airport en route to Ontario, California. The sunset was at 5:25 p.m., so it was already fairly dark. When the aircraft reached approximately 16,300 feet (about 5,000 meters), the passengers heard a loud boom as the door blew out from the side of the aircraft.

Everyone on board survived, and the aircraft landed in Portland shortly after, but I am sure most passengers will have a different experience with air travel from that point forward. Many years ago, I was in a much less dangerous but scary landing that did not go as planned (no, not the runway miss with a fly-around, which I experienced twice and is not a big deal), but something more extreme. Since then, I have never been entirely comfortable during unexpected turbulence.

Conditions at 16,300 Feet and Above

The air temperature at this altitude is approximately 0 F (-17 C), and outside air pressure is about 54 kPa (kilo-Paskals) or about 8 PSI (pounds per square inch). For reference, sea-level air pressure is about 101 kPa or 15 PSI. This pressure is the column of air pushing on you as you stand on the ground, and by convention, this gives us yet another unit of pressure — 1 atm (atmosphere). Pressure is related to the number of air molecules available for each breath since the pressure is directly proportional to the density (this comes from the ideal gas law, which I will touch on later). At the cruising altitude of 33,000 feet (about 10,000 meters), the air temperature is about -50 (here, C and F units are close to each other), and air pressure is about 19.3 kPA.

At 8,000 feet and higher, there are not enough air molecules for most people to breathe, so modern aircraft are pressurized (sealed with cabin pressure controlled by the Environmental Control System).

Ideal gas law and what happens during the change in altitude

The fact the door blew out during the ascent was no accident, pardon the pun, and can be explained by the ideal gas law.

\[
pV = nRT
\]

The key quantities are Pressure \(p\), Volume \(V\), and Temperature \(T\). The other quantities are constants, so we can write:

\[
pV \propto T
\]

From the ideal gas law, pressure is inversely proportional to volume—as pressure decreases, the volume of gas increases, and vice versa. This makes some intuitive sense, as you can imagine what happens when you reduce the volume of a sealed container; the pressure inside goes up and vice versa.

When the pressure outside the sealed container rises, say during a submerging process, the walls experience an inward pressure due to a pressure differential, and when the outside pressure falls, say during an ascent, the wall experiences an outward pressure.

This is why, during a scuba lesson, you are told to keep your mouth open on the ascent so that expanding air doesn’t damage your lungs. For the same reason, when a flight attendant hands you a bag of chips at 30,000 feet, the bag appears inflated2.

This outward pressure on the fuselage caused the blowout, and we will now try to estimate how much pressure it took for the door to separate.

Computing the pressure on the fuselage

As a statistician, it always blows my mind how much we can learn from n=1 “experiments” if we are willing to bring some background knowledge, the ideal gas law in this case, to bear on the problem. Physicists would not be impressed, as to them, this is par for the course.

Anyway, back to our problem. To make the calculations, we need to make a couple of key assumptions, namely the pressure outside the aircraft as it climbs and the pressure inside the cabin. The drop in atmospheric pressure with altitude is well-known and follows an exponential decay according to the Barometric formula. This is the blue line in the following diagram.

The green and red horizontal bard indicate my error in assuming gradual cabin pressurization. The dashed line represents the altitude at the time of the accident.

The second assumption we need is the pressure inside the cabin. First, I assume that the target inside pressure is equivalent to about 6,000 feet (1,800 meters), which is at the lower end of the reported range. This type of pressurization balances the passengers’ comfort with the force that the fuselage has to withstand.

Second, I (erroneously) assumed that the pressure is gradually adjusted to reach the target at the cruising altitude of 33,000 feet, the green curve on the above diagram. I later learned that the target pressure is typically reached relatively quickly after takeoff and that the cabin pressure was most likely at its target at the time of the accident. This means that my green curve would drop much more quickly and remain flat for the rest of the flight. The green and red vertical bars at the height of the accident represent this error.

To compute the outward pressure on the fuselage (red), we take the difference between the two curves at 16,300 feet, which gives us 26 kPa, assuming the aircraft was pressurized to about 1,800 meters at the time of the accident. (If we incorrectly assume gradual pressurization, the pressure would be about 36 kPa.)

To make this more interpretable, we can compute how much force (in lb or kg-equivalent units) was applied to the door. We will assume the door is nearly rectangular with 72 x 34 inches (183 x 86 cm) dimensions, taken from a 737 manual. To compute the weight in pounds:

\[
W = P \cdot A \cdot 2.2/g
\]

P is the pressure in kPa, A is the area in square meters, and g is the gravitation constant. This turns out to be about 9,400 lb (4,300 kg), which I rounded to 9,000 lb in the diagram. At the cruising altitude of 10,000 meters, the weight on the door would be approximately 19,000 lb (~ 8,600 kg).

Conclusions

When the aircraft finally landed, the passengers were treated to the following view of the airfield.

The calculations can make us appreciate how much force every 1.6 square meters of fuselage must withstand, so constructing a well-pressurized cabin is an impressive engineering achievement, while forgetting to put a few screws into the door plug during a final assembly is a massive management oversight.

One can imagine a situation where the door was a bit more secure than it was (but still not fully installed) and that the separation would have happened at 33,000 feet instead of at 16,000. What then? I am not sure what the immediate depressurization at that altitude would do to a human body (if your mouth and nose are closed, your lungs may rupture; you may also suffer from decompression sickness; if you don’t put on the oxygen mask, you will suffocate), much less if the pilots could descend fast enough to avoid hypothermia and other pleasantries.

Up or Down

In June 2023, a submersible operated by OceanGate imploded near the remains of the Titanic. The Titanic is located at 12,500 feet (3,800 meters) under the sea, and the pressure at that depth is about 38,000 kPa, 380 times more than at the surface (~ 380 atmospheres). When the implosion was originally detected, the Coast Guard undertook a massive search and rescue operation. The rescue part was a fool’s errand — at this pressure, the passengers were instantly disintegrated.

  1. In 2019 and 2020, the 737 Max was involved in two accidents relating to the angle of attack sensors. ↩︎
  2. Why should the bag inflate inside the plane? That’s a good question, and this should be the clue that the cabin’s pressure is not kept at sea level but adjusted downward as the plane climbs. ↩︎

Does pair programming apply to statistics?

New Yorker recently published an article entitled “The Friendship That Made Google Huge.” The article describes a collaboration between Sanjay Ghemawat and Jeff Dean, two early Google employees responsible for developing some of the critical pieces of Google’s infrastructure. 

One of the of the fascinating aspects of this collaboration was that they programmed together, a practice known as pair-programming. One person typically drives by typing and other is navigating by commenting, pointing out alternative solutions, spotting errors, and so on. The benefits of pair programming cited by c2 are increased discipline, better code, resilient flow, improved morale, collective code ownership, mentoring, team cohesion, and fewer interruptions. These seem reasonable, although I am not sure how much work went into validating these attributes. 

Reading the article I was wounding what would the application of this technique to Statistics would look like. And I don’t mean to the computational aspect of Statistics. It seems pretty clear that if we are collaborating on the development of statistical software, pair-programming could be applied directly. But what about the process of say thinking about a new statistical algorithm?

When I started attending Stan meetings in Andrew Gelman’s office, I think around 2015, they were still a lot of fun. A few people usually gathered in a circle and discussions often took off on a statistical tangent. That was the best part. I remember one time Andrew went up to the blackboard and said something like “I have been thinking about this idea for optimizing hyper-parameter values in hierarchical models…” and proceeded to scribble formulas on the board. This was the beginning of what he dubbed a GMO (Gradient-based marginal optimization) algorithm. See here from Bob Carpenter for more details. I think he wanted to get some feedback and stress-test his ideas by writing them on the board and having other people comment. I am not sure if this qualifies as pair-statisticsing (more like three-pair), but maybe close enough? 

Scientists collaborate all the time, although there are loners like Andrew Wiles, for example. But what about a close collaboration where two people sit next to each and one is writing and the other commenting or more likely using the same blackboard?  It seems like it would be a useful exercise. I for one would be too embarrassed to undertake it. I should try pair-programming first.

Talks, Lectures, and Workshops. What is the Difference?

group learning

I am about to go on a mini speaking tour and in preparation I am skimming Scott Berkun’s “Confession of a Public Speaker.” I like this book, but while reading it I realized that I will be giving two different types of “speeches”. Let’s call them talks and workshops, and even though in both cases the subject will be Stan, the audience’s expectations will be different and my presentation must reflect those differences. In particular, Scott’s book is a lot more relevant to talks than workshops.

Most inexperiences speakers assume that the people who come to their talks want to learn something and some people do have that expectation, but those are usually inexperienced consumers of talks. The truth is that it is very unlikely that you will learn something during a talk. Learning is a hard and active process and it is not going to happen by passively absorbing sound and light waves in a reclining position.  The most realistic goals for a talk is to inspire people to learn more about the subject. This is a difficult task for the presenter, but if you want to know how to do it well, I highly recommend Scott’s book.

A workshop is a different animal. As the name suggests, the participants will be working alongside the presenters and in so doing are hoping to come away with enough initial knowledge to jump start their own exploration. People who attend the workshop have already been inspired to learn more and the bar is therefore higher than during a talk. So what are the important attributes of a good workshop?

To think about that, image you are taking a technical class at a University. You are listening to a lecture. Are you at a talk or at a workshop? The listening part gives it away. Most likely you are at an uninspiring talk that should instead be a workshop. In order for the workshop to go well, here is my short of list of requirements:

  1. Participants should have the required background at the right level of abstraction
  2. If this is a computing workshop, participants already installed and tested the required software
  3. Presenters have designed a series of exercises that gradually guide the audience through a set of hands on tasks each illuminating a different part of the subject
  4. Participants have a chance to discuss the problem and their solutions with each other and with the instructors
  5. There is a mechanism for the immediate feedback that tells the instructors if the majority have mastered the task

As a presenter, I can not control 1 and 2, but I must make it easy for people to assess their level of knowledge and software installation instructions must be clear.

Creating exercises is very time consuming, but I believe necessary for workshop style learning. Time for discussions can be weaved into the exercises and the output of the exercises can be shared with the rest of the class. Which brings me to the feedback mechanism, which is perhaps the most often overlooked aspect of the workshop.

I don’t have much experience with a feedback system during workshops, but I have used live surveys during talks and they work really well. For computing workshops, I would like to experiment with live code editors, where participants have a chance to post their code, their questions, and the error messages to the shared workspace. This would only work for moderate size groups, but I it seems to me that workshops should only be conducted in relatively small groups (say 50 people or fewer).

If you have any pointers on how to make the workshop experience better, feel free to post them in the comments.