Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Miami Pedestrian Bridge, Part X 50

Status
Not open for further replies.

JAE

Structural
Jun 27, 2000
15,432
0
36
US
A continuation of our discussion of this failure. Best to read the other threads first to avoid rehashing things already discussed.

Part I
thread815-436595

Part II
thread815-436699

Part III
thread815-436802

Part IV
thread815-436924

Part V
thread815-437029

Part VI
thread815-438451

Part VII
thread815-438966

Part VIII
thread815-440072

Part IX
thread815-451175



Check out Eng-Tips Forum's Policies here:
faq731-376
 
Replies continue below

Recommended for you

OSHA .pdf page 84 said:
As a result of the blow-out, three #7 shear reinforcements at the construction joint of diagonal 11 and the deck were sheared but the southernmost shear reinforcement remained intact. The width of the blow-out was 2 ft. at the southern end gradually enlarging towards the north. The blow-out encompassed the two 4” pipes on either side of column 12, and was symmetrical to the center line of the deck.
There had been some question regarding the rebar...

SF Charlie
Eng-Tips.com Forum Policies
 
It may be a little late in the game but here is my animation of the collapse based on the dash cam video. I've taken seven screen shots, rotated the images to align the orientation with the canopy section from 11 -12 and then centered them with the white figure on the #11 banner. I've attached a GIMP image file of the seven layers for better clarity of the subtle details.

I believe this shows clearly that #11 ruptured at the base (puff visible in image 2), then the canopy snapped along with the top of #11, then as #11 is pile driven into #12 evacuating a significant amount of concrete from its bottom end , #12 is pulled over and down off of its base by the canopy section which is still attached to the larger canopy by the PT bars (layer 5 and 6). I believe #11 needed to loose about 7 feet of length to straight line with the long canopy. The slab dropping from the pylon does not occur until after this sequence. This also helps to explain why the lower PT bar in #11 is kinked upward at the slab (or sheared per OSHA).

FIU_Bridge_Dash_Cam_Video_feapb0.gif
 
I believe the project FDOT & FHWA standards are from 2014, based on the date of the TIGER Grant.

FDOT Tom Andres repeatedly pointed out the issue with the 11/12 node not being captured by the longitudinal PT tendons as early as the 30% Submittals Plans in March 2016 & again in the 90% Construction Plans.

FIGG did not contract for 30%, 60% & 90% PEER Review as required by FDOT. They originally tried to finagle FDOT to allow one of their OTHER FIGG offices do the PEER Review. They finally finagled FDOT to agree to PEER Review when plans were at 100% Construction ready but they used that instead to contract with Louis Berger for a 100% completed structure PEER Review instead of the still required incremental PEER Review. Louis Berger submitted the PEER Review Certifications to Alfredo Renya the FDOT LAP Coordinator, bypassing FDOT Structural Reviewer: Tom Andres. This seems a bit slippery behavior by FIGG.

During an interview with FIGG, OSHA quizzed FIGG about the lack of Redundancy. FIGGS reply was that the numerous PT bars were a form of Redundancy. Let’s hope that was Linda Figg & not Denny Pate.

FDOT’s Tom Andres was also concerned about the 12/Canopy region in front of the Canopy Blister.

What if some of the Sag in the bridge during transport remained as camber, until Truss No. 2 & Truss No. 11 are detensioned? I’m just trying to visualize the load path. At the South end (FIU) there are two bearing pads. At the North Pylon (Canal) there are 4 pedestals with stacked shim plates. It seems any longitudinal settling from SPMT move induced camber would take place to the north. So when Truss No. 2 & Truss No. 11 are detensioned, Truss No. 11 tries to kick out the base of Vertical No. 12 as the deck and canopy try to flatten out. The detensioning having a more immediate effect on the uncaptured Vertical No. 12, than on the deck & canopy.
 
Sym P. le - your "dash cam video" from Joel Franco's YouTube channel is one of many fuzzy interpolated versions. Here is the highest quality version that I've found. You can clearly read the ID number on the school bus bumper: 32082. It appears to be sped up, but this is what the original footage looked like, as I explained in my post of MikeW7 (Electrical) 12 Jul 18 02:16 in Part VIII.
 
Thanks Mike, I'll see if I can improve on the images. Did you check my GIMP file, the images are much clearer than the GIF. I was more interested in the overlay and reorientation of the images to see if it could give a better understanding of the collapse sequence.
 
Sym P. le - I just checked your video link and saw that it was a low-quality version (fuzzy, can't make out ID number on bus bumper). The YouTube owner, JoelF (Franco), is some kind of free-lance journalist and he was sent (or obtained) one of the first copies of the dash-cam video. The original source video, as far as I can tell, was obtained directly from the truck driver by a web developer with the handle o2webdev. He posted it on his FB and IG, where some of the local media (Miami Herald, etc.) found it, and he ended up deleting all his social media accounts shortly after that. I got my shortened copy from somebody's FB before they deleted it.

The original truck dashcam video actually starts in the MCM construction area. You can see the flatbed truck being loaded by the blue mobile crane at top center starting at 2:22 in the N view collapse video, and again in the last frame of the video, at far right.
 
MikeW7 said:
I just checked your video link and saw that it was a low-quality version (fuzzy, can't make out ID number on bus bumper).

... but most important is whether or not it's interpolated in time, as you previously pointed out. If an assessment like Sym P. le's is based on a time-interpolated version, then it's just assessing the interpolation method and model, literally the morphing method that generates the intermediate frames, not what the bridge actually did.
 
MikeW7: Back in the old days of Part IX (!) you were assembling videos that focused on when personnel inspected parts of the bridge. The appearance of the OSHA report perhaps drained some of your momentum, but I wonder if you have made any observations of whether the various inspections noted in the OSHA report can be seen happening in the videos, as might be determined by approx time of day?

One episode that would be interesting to see is "March 15, 2018 Two structural engineers from FIGG, Denney Pate and Eddie Leon arrived at the site approximately 7:45 am to examine the cracks first by walking over the deck. Thereafter, they evaluated the cracks by using a man-lift for better access. Also present were MCM’s Rodrigo Isaza and Pedro Cortes, and BPA’s Jose Morales. Denney Pate and Pedro Cortes went up in a man-lift, and examined the cracks."
 
Here are the individual images. They seem blurry (are soft) because the video poster cropped and magnified the video, and this is to our advantage. I'm not sure I can do much better in a short period of time.
Frame_1_cxpiw0.jpg

Frame_2_ult0vb.jpg

Frame_3_lslybm.jpg

Frame_4_jwrwi0.jpg

Frame_5_zfxqxt.jpg

Frame_6_dx0ozi.jpg

Frame_7_faeysr.jpg
 
qwideman - I've got all the videos cut out and processed (15 total), just haven't got them uploaded yet. I will put them in a separate playlist. I found 4 separate inspections on the 12th, 3 on the 13th, and 2 closely spaced ones on the 14th which I just left as one combined video. No activity noted on the afternoon of the 10th, or on the 11th. Most of them are duplicated in N and SW views, but the N view camera malfunctioned on the 12th (visible wind buffeting and raindrops on lens). In the descriptions I'll add time-stamps (and frame numbers) for the start of each clip within the original timelapse.
 
Sym P. le - Attached is a 9-frame video, with individual JPGs of each frame. They are cropped to 212x203 (original video was 1280x720).
NOTE: "Zoom, enhance, zoom, enhance" only works in the movies.

UPDATE: I will try again tomorrow. The JPGs I made are distorted...
 
Sym P. le said:
yet another post based on bogus images

Please please read the previous forum posts about these interpolated videos. You are not analyzing evidence, you are analyzing the model used to interpolate, which means you are muddying the waters by claiming that these images tell us anything useful.

As MikeW7 pointed out 28 Mar 18 22:52, the dashcam video was capturing at 5 frames per second. And read here for how intermediate frames are interpolated, in that case by Zac Doyle:

Note in particular that the frames are interpolated (morphed) by the user manually drawing reference points. A user will generally place the points to show more or less linear motion. The user will not know if some abrupt accelerations, deccelarations, or changes of direction took place in the 200 milliseconds between video frames. The author of that blog post wrote:

"However, as I mention above, there are errors present in the rendering. One consideration you mentioned was the possibility that the motion is being linearly interpolated between the points, as in they move in a straight line from point A to point B. That is absolutely correct in regard to how the motion is interpolated in this. I could correct for a more expected curved motion for the reference points. However, its more challenging to get this correct in the short time I was spending on this."
 
You may choose to disregard this, others may find it useful. Poor video is better than no video. I chose to present it in a different manner. The movements I've referred to are significant, even in terms of the limited quality of the source. The time span covered is less than 2 seconds, probably closer to 1.4. This is the smoking gun on the collapse sequence. Period.
 
I know a thing or two about videos and engineering. Don't be so quick to dismiss it. I could always be wrong, but maybe I'm not. I think it is far more real than you are willing to give it credit for. I'm willing to stand on this one. To be sure, I am presenting an animation, a sequence of images, sourced from a video.
 
So Denney Pate's wife never checks pockets of pants before dumping them in the washer? Nothing suspicious there.

If they have the phone I expect it can be returned to working order. It doesn't need to go to Cellebrite first, it needs to go to iPad Rehab or similar repair company to fix whatever component made the battery angry; usually going to be something small that handles higher power rather than a SOC and memory chip.
 
After spending a couple hours this morning trying to figure out how to "properly display" images I've come to the conclusion that it is darn near impossible. Anything that displays an image, be it a viewer or editor or browser, automatically processes the crap out of a small image as it is enlarged to protect you from the embarrassment of seeing square mono-colored pixels in their naked glory. As such, it is very difficult trying to illustrate how difficult it is to "zoom, enhance" a low-resolution video and expect it to provide a divine revelation.

Here's the best I could do. I took the original "high-quality" truck cam video, original format 1280x720, and used VirtualDub2 to crop out a 200x200 image at frame 70. VD2 is one of those rare applications that lets you see something resembling real square pixels in its work window. Then I took a Windows PrintScreen from my 4K monitor and pasted the capture into another of my favorite free apps, IrfanView, cropped the PrintScreen image, and saved it as a JPG with 100% quality:
frame_70_cropped_ayrztn.jpg

The result is an 2509x2160 image that preserves most of the original 200x200 video frame chunkiness and allows you to see just how lego-like the video details really are. Note the stair-stepped diagonals.

Next I used the VD2 Rotate2 filter to spin this frame -30 degrees, and did an identical work flow to process a screen capture:
frame_70_cropped_rotated_xhcxop.jpg

The result is a confusing, blocky mess, but this is what the real raw data looks like. It can be edited to look "cleaner" and "more realistic" but doing so severely damages the true visual data.

In closing, this isn't intended to be a criticism, just a friendly reminder that whenever you work with computers you are plugging into the Matrix, and the onscreen "reality" isn't always what it seems to be.
 
Status
Not open for further replies.
Back
Top