The collapse of the Florida International University pedestrian bridge will undoubtedly result in some serious soul searching by the engineering community. In looking at it from the outside, my first gut instinct tells me that there was an error in the structural analysis of this rather pretty, but really quite complex structure, while it was only partially installed. I suspect this structure was designed with the use of a finite element (FEM) program, and since it is a non-conventional reinforced concrete structure, the analysis is far from straight forward. I could very well be wrong, but, at this stage, I suspect that the program misinterpreted, or did not recognize, a failure mode in the erection stage that eventually resulted in the collapse.
I am tending towards such a conclusion, because in the last few weeks I have been struggling with a weird result in a fancy hydrostatics program. We were analyzing the sinking of a small sportfishermen and trying to determine what happened in the last few seconds before sinking.
Sinking calculations tend to stress fancy hydrostatics programs, because flooding, free surface, tankage, permeability and freeboard assumptions become vital, and small variations can result in large changes in results.
We were studying one set of assumptions and it showed that the vessel would settle quite nicely when it flooded and then, suddenly, the free water surface would shift aft and the resulting weight shift would cause the vessel to immediately sink by the stern. However, when I was looking at the results, I could not convince myself that the astern weight shift of the free water was enough to settle the vessel sufficiently by the stern for the water to come over the cockpit coaming. (An exact manual calculation for this is brutal, but estimates are really not that difficult to make.) In my estimation there should still be about a foot freeboard at the cockpit coaming.
I brought this to the attention of the model developers and told them that I felt the result was wrong. This resulted in significant resistance, and defensive arguments along the line of: “But this is a USCG approved program, it cannot be wrong.”
We double checked the input and could not find anything that was wrong, but the odd result still kept nagging at me. So we did what I learned to do when I did my first big software development many years ago; we altered the model so it could not fail in the mode it calculated. We just raised the freeboard by a ridiculous amount.
The boat still sank by the stern. Now we knew something was not working right within the program. It took a while, but we figured out that while the transom was not modeled to be open, the program assumes it is open. This is a modeling conundrum that occurs using station based computer programs. Because the cockpit coaming looked like a bulwark, and because most stability standards do not provide stability or floatation credits for bulwarks, this particular hydrostatics program idiosyncrasy does not normally cause any problems, but here it did.
Ironically, if this model had been run in a much simpler hydrostatics program (like Project 114), it might have worked correctly, but because it used a “USCG” approved hydrostatics program, it returned incorrect results for this application.
Really scary stuff, but really not that unusual.
I cannot help but think back at two other, fortunately mostly harmless, computer program fails that I encountered:
1. While working on the 1987 America’s Cup campaign, my boss always forced me to manually plot the model basin data. This was frustrating because, often, my manual plots would not match up with the computer results provided by the model basin program. Again, it took quite some effort, but we discovered that computerized curve fitting along three points can be quite random when the computer has absolutely no idea what those curves normally look like. Meanwhile competing syndicates, using the same model basin, were claiming massive performance improvements based on their model tests. We never told them to check the curve fits in their computer programs.
2. While salvaging a grounded container vessel, I asked the Chief Mate why the vessel had such a weird tall stack of boxes portside on the No. 1 Hatch and another weird tall stack starboard on the aftermost Hatch. He told me the ship had a torsional limit and this was to get rid of it. Torsion can be confusing, but it made no sense to me. So I checked it in the loading computer program and, sure enough, only when you stacked boxes like that, did it get rid of the torsional stress. But uneven stacks increase torsion, it sure looked like somebody had used a plus, instead of a minus in the program somewhere. There was a London phone number on the manual and I called the program developer. I raised the subject, and I received a proper haughty British stiff lip accented denial: “Impossible! The manual was approved by Lloyds Register, and the vessel you are on is the 20th in a series of 26 identical ships and nobody has ever mentioned that!” My answer was simple: “Well, if you are so sure, why not run your copy of the program, and make a nice big stack port forward and starboard aft and see what happens.” They called back 20 minutes later and promised to send me a corrected version (which never ran right either, because, with complex computer programs, quick fixes rarely are the right fixes.)
But while waiting for the update, I had made a quick estimate that indicated that over 100 manyears of use between these sisterships had failed to identify the error, meanwhile consistently overtorqueing these vessels. Scary stuff, and the “why?” for that is complicated. The FIU investigation may provide some further insights in that regard, unfortunately at an unacceptably high cost. An error was made, but most of all, as engineers, let’s not forget to learn from it.
