WEBVTT 1 00:00:00.160 --> 00:00:03.359 Right now, somewhere in the world, an engineer is staring 2 00:00:03.399 --> 00:00:04.599 at a computer screen. 3 00:00:04.480 --> 00:00:07.440 Yeah, probably looking at a beautifully colored three D model 4 00:00:07.480 --> 00:00:10.160 of a massive concrete dam or something. 5 00:00:09.919 --> 00:00:13.880 Exactly, and the screen lights up with these brilliant reassuring 6 00:00:13.919 --> 00:00:17.640 contours like red means high stress, blue means low stress. 7 00:00:17.719 --> 00:00:19.440 Right looks so clean, it. 8 00:00:19.359 --> 00:00:22.199 Does, And the software points at the graphic and essentially says, 9 00:00:22.199 --> 00:00:25.559 you know, the dam is perfectly safe, and it is 10 00:00:25.640 --> 00:00:29.519 incredibly tempting to just accept that. We like our engineering 11 00:00:29.519 --> 00:00:34.079 to be highly visible, neatly categorized, and safely handled by 12 00:00:34.079 --> 00:00:34.560 a computer. 13 00:00:34.719 --> 00:00:37.520 It feels clean, Yeah, it gives this a sense of 14 00:00:37.640 --> 00:00:41.439 absolute certainty. But underneath those pretty red and blue stress 15 00:00:41.520 --> 00:00:45.320 contours is a completely opaque mathematical black. 16 00:00:45.079 --> 00:00:47.079 Box, a total black box. Yeah. 17 00:00:47.200 --> 00:00:49.679 The moment you step out of that polished user interface 18 00:00:49.880 --> 00:00:51.960 and try to actually understand the mechanics of what the 19 00:00:52.000 --> 00:00:54.880 computer is doing to your digital structure, that certainty just 20 00:00:55.119 --> 00:00:57.960 it vanishes. You are looking at a computational landscape that 21 00:00:58.079 --> 00:00:59.920 is honestly pretty. 22 00:00:59.759 --> 00:01:02.840 Marked, and if that engineer doesn't know exactly how the 23 00:01:02.840 --> 00:01:05.959 computer is doing its math, that dam could fail in 24 00:01:06.000 --> 00:01:09.000 the real world despite what the pretty colors say absolutely, 25 00:01:09.239 --> 00:01:12.400 which is exactly why we are here today. Welcome to 26 00:01:12.480 --> 00:01:15.519 the deep dive. Whether you are an engineering student grinding 27 00:01:15.560 --> 00:01:19.359 through your first structural analysis course, a young professional trying 28 00:01:19.400 --> 00:01:21.959 to understand why your soil model just crashed at two 29 00:01:21.959 --> 00:01:24.879 in the morning, or a self taught learner who just 30 00:01:24.959 --> 00:01:28.640 has an insane curiosity about how massive things stand up 31 00:01:28.640 --> 00:01:30.599 and fall down, this is for you. 32 00:01:31.000 --> 00:01:33.000 We are going to be opening up that black box. 33 00:01:33.079 --> 00:01:33.640 Yes we are. 34 00:01:33.840 --> 00:01:37.040 Our mission today draws on a phenomenal source text. It's 35 00:01:37.079 --> 00:01:40.040 the fifth edition of Programming the Finite Element Method by 36 00:01:40.040 --> 00:01:43.200 I AM Smith, D. V. Griffiths, and L. Margets. The 37 00:01:43.239 --> 00:01:46.439 goal here is to bridge the massive gulf between understanding 38 00:01:46.480 --> 00:01:50.120 finite element theory on a classroom whiteboard and actually writing 39 00:01:50.159 --> 00:01:52.000 the computer programs to execute it. 40 00:01:52.120 --> 00:01:54.120 I am so excited to peek under the hood here. 41 00:01:54.280 --> 00:01:57.799 I mean, relying on commercial software is fine for basic, 42 00:01:57.879 --> 00:02:00.599 everyday tasks, but if you want to be a true 43 00:02:00.680 --> 00:02:03.959 master of civil engineering, you need to know exactly how 44 00:02:04.000 --> 00:02:08.719 that code interacts with physical dirt, flowing water, and yielding steel. 45 00:02:09.800 --> 00:02:14.439 We are going to translate dense matrix algebra into practical reality. 46 00:02:14.520 --> 00:02:16.879 Yeah, we're taking the jargon out of it exactly. 47 00:02:17.319 --> 00:02:19.840 But before we can model a massive skyscraper or a 48 00:02:19.919 --> 00:02:23.879 deep excavation site, we have to understand the fundamental materials 49 00:02:24.080 --> 00:02:26.719 of our software. We need to talk about the structure 50 00:02:26.759 --> 00:02:27.599 of the code itself. 51 00:02:27.680 --> 00:02:31.840 Well. The underlying architecture relies heavily on for trand two thousand. 52 00:02:31.599 --> 00:02:33.000 And eight, which sounds a bit retro. 53 00:02:33.199 --> 00:02:35.560 It does now. For trend might sound old school to 54 00:02:35.960 --> 00:02:38.759 you know one developers, but in the realm of heavy 55 00:02:38.960 --> 00:02:43.800 scientific matrix computation, it remains an absolute powerhouse. Oh wow, Yeah, 56 00:02:43.840 --> 00:02:47.280 the authors haven't written one giant, monolithic program that you 57 00:02:47.360 --> 00:02:49.520 just hit run on. They've actually built a library of 58 00:02:49.560 --> 00:02:51.919 over one hundred modular procedures. 59 00:02:52.199 --> 00:02:54.439 Okay, let's unpack this for a second. It's it's like 60 00:02:54.520 --> 00:02:55.400 digital legos. 61 00:02:55.639 --> 00:02:56.599 I love that analogy. 62 00:02:57.080 --> 00:02:59.520 Right, If you are building a model, you don't need 63 00:02:59.560 --> 00:03:02.680 to rein invent a custom mathematical operation every single time 64 00:03:02.719 --> 00:03:05.680 you want to multiply two massive matrices together. You just 65 00:03:05.759 --> 00:03:08.759 reach into the bucket, grab a pre compiled building block 66 00:03:08.840 --> 00:03:12.000 routine for matrix multiplication, and snap it into your main 67 00:03:12.039 --> 00:03:13.319 program exactly. 68 00:03:13.400 --> 00:03:17.400 And what's fascinating here is that modular approach gives you 69 00:03:18.000 --> 00:03:19.840 the engineer ultimate. 70 00:03:19.520 --> 00:03:21.919 Control because you aren't boxed in right. 71 00:03:22.199 --> 00:03:26.439 If you rely on closed source, proprietary software, you are 72 00:03:26.520 --> 00:03:30.039 trapped by their assumptions. You can only solve the specific 73 00:03:30.080 --> 00:03:32.280 problems their developers anticipated. 74 00:03:31.719 --> 00:03:32.879 Which is a huge limitation. 75 00:03:33.039 --> 00:03:36.919 It is by using fundamental building blocks you dictate the physics, 76 00:03:37.360 --> 00:03:42.319 and perhaps more importantly, this exact same logical architecture scales seamlessly. 77 00:03:42.400 --> 00:03:43.439 What do you mean by scales? 78 00:03:43.719 --> 00:03:46.000 Well, the physics of how a steel beam bends don't 79 00:03:46.080 --> 00:03:48.520 change whether you are running a simple one D test 80 00:03:48.520 --> 00:03:52.360 on a personal laptop or analyzing an entire suspension bridge 81 00:03:52.360 --> 00:03:54.520 on a massively parallel supercomputer. 82 00:03:54.800 --> 00:03:57.719 That makes total sense. So we have our digital lego blocks, 83 00:03:58.599 --> 00:04:00.879 but how do we use them to map out a 84 00:04:00.919 --> 00:04:04.719 continuous physical reality? I mean a jagged mountain face or 85 00:04:04.759 --> 00:04:08.479 a complex bolted connection. Isn't made of neat little blocks, No. 86 00:04:08.599 --> 00:04:13.199 They aren't. Mathematically, you cannot solve continuous differential equations for 87 00:04:13.319 --> 00:04:16.279 a complex random geometry. It's just impossible. 88 00:04:16.480 --> 00:04:16.920 What do we do? 89 00:04:17.079 --> 00:04:21.319 So we discritize. We take that continuous physical object and 90 00:04:21.439 --> 00:04:25.319 chop it up into a grid of localized, simplified pieces. 91 00:04:25.360 --> 00:04:26.680 Those are your finite element. 92 00:04:26.800 --> 00:04:29.439 Okay, and this all boils down to one fundamental formula 93 00:04:29.480 --> 00:04:31.920 that governs almost everything we were talking about today. Right, 94 00:04:32.439 --> 00:04:36.279 Stiffness times displacement equals force. That's the one. So if 95 00:04:36.279 --> 00:04:38.319 I push on something, how much does it move? Based 96 00:04:38.319 --> 00:04:39.079 on how stiff it is? 97 00:04:39.160 --> 00:04:42.759 Precisely, and the physical shape of those finite elements dictates 98 00:04:42.759 --> 00:04:45.600 how we calculate that stiffness. Okay, you might start with 99 00:04:45.720 --> 00:04:48.759 simple one D rods or two node beams for like 100 00:04:49.040 --> 00:04:51.560 a truss bridge. Then you move up to four node 101 00:04:51.600 --> 00:04:54.120 quadrilaterals for analyzing a flat concrete slab. 102 00:04:54.240 --> 00:04:55.120 Right, getting more complex? 103 00:04:55.279 --> 00:04:58.600 Yeah, And finally, for complex solid structures, you move up 104 00:04:58.600 --> 00:05:02.360 to twenty node hexahedra, which are basically sophisticated three. 105 00:05:02.319 --> 00:05:03.399 D bricks thood bricks. 106 00:05:03.399 --> 00:05:05.560 Got it? For each of these shapes, one of our 107 00:05:05.800 --> 00:05:09.560 digital Lego building blocks is a subroutine that numerically integrates 108 00:05:09.560 --> 00:05:13.439 its geometry to figure out its unique stiffness matrix. 109 00:05:13.480 --> 00:05:16.720 Wait, hold on, If we are chopping a massive dam 110 00:05:16.839 --> 00:05:20.839 into say one hundred thousand three D bricks, and we 111 00:05:20.879 --> 00:05:24.120 can calculate this stiffness for each brick, yeah, why can't 112 00:05:24.160 --> 00:05:26.959 we just take every single elements matrix grow them all 113 00:05:27.000 --> 00:05:30.720 together into one massive system wide global stiffness matrix and 114 00:05:30.800 --> 00:05:32.120 just solve the whole dam at once. 115 00:05:32.279 --> 00:05:34.920 So what does this all mean? In practice? That traditional 116 00:05:34.959 --> 00:05:38.040 approach is known as global assembly, and it works beautifully 117 00:05:38.040 --> 00:05:40.040 for one D frameworks or small two D. 118 00:05:40.079 --> 00:05:41.800 Problems, but not for the big stuff. 119 00:05:41.959 --> 00:05:44.519 No, if we connect this to the bigger picture, the 120 00:05:44.560 --> 00:05:48.000 physical reality of computer hardware catches up with you really fast. 121 00:05:48.279 --> 00:05:51.920 A matrix for one hundred thousand three D elements is gigantic. 122 00:05:51.959 --> 00:05:54.399 We're talking gigabytes maybe terabytes and size. 123 00:05:54.519 --> 00:05:55.000 Oh wow. 124 00:05:55.040 --> 00:05:57.360 And here is the kicker. The vast majority of that 125 00:05:57.399 --> 00:06:00.000 matrix is completely empty space. It's just zero. 126 00:06:00.279 --> 00:06:01.199 Wait why is it empty? 127 00:06:01.319 --> 00:06:03.439 Because a concrete node on the far left side of 128 00:06:03.439 --> 00:06:05.959 the dam doesn't directly interact with a node on the 129 00:06:05.959 --> 00:06:06.879 far right side. 130 00:06:07.000 --> 00:06:09.720 Oh okay, So if I try to assemble that globally, 131 00:06:09.879 --> 00:06:14.839 I'm forcing my computer to memorize millions of useless zeros. Exactly. 132 00:06:14.920 --> 00:06:17.680 I'll literally crash my work station trying to store empty space. 133 00:06:17.920 --> 00:06:21.680 So if we can't build one giant global matrix, how 134 00:06:21.720 --> 00:06:23.480 on earth do we solve the system. 135 00:06:23.600 --> 00:06:26.519 That's where we swap to an iterative approach. The book 136 00:06:26.560 --> 00:06:30.360 introduces something called an element by element technique or ebe 137 00:06:31.040 --> 00:06:35.120 relying on a preconditioned conjugate gradient solver a PCG right, 138 00:06:35.120 --> 00:06:38.480 a PCG. So, instead of building a giant matrix to 139 00:06:38.560 --> 00:06:43.120 solve all the simultaneous equations directly, the PCG solver calculates 140 00:06:43.160 --> 00:06:46.360 the necessary matrix vector products on the fly, one element 141 00:06:46.399 --> 00:06:46.879 at a time. 142 00:06:47.000 --> 00:06:47.879 That is so smart. 143 00:06:47.959 --> 00:06:51.040 It only keeps the local neighboring element matrices and memory, 144 00:06:51.399 --> 00:06:54.000 passing the forces back and forth until the whole system 145 00:06:54.000 --> 00:06:55.319 settles into a balanced answer. 146 00:06:55.519 --> 00:06:58.360 That is a brilliant workaround. We aren't just doing math. 147 00:06:58.680 --> 00:07:01.439 We are actively managing the physical memory limits of our 148 00:07:01.480 --> 00:07:04.759 computers to execute better maps for you, the listener. This 149 00:07:04.920 --> 00:07:07.560 is the difference between your soil model running in ten 150 00:07:07.600 --> 00:07:10.560 minutes so you can actually go home, versus blue screening 151 00:07:10.600 --> 00:07:11.120 your computer. 152 00:07:11.480 --> 00:07:12.160 It really is. 153 00:07:12.480 --> 00:07:16.120 But so far, this beautifully balanced MAB assumes our materials 154 00:07:16.120 --> 00:07:19.199 are perfectly elastic, like a rubber band. You pull a steel, 155 00:07:19.279 --> 00:07:22.079 it stretches, you let go, it snaps back perfectly. 156 00:07:22.279 --> 00:07:25.600 Yeah, but real dirt, concrete, and steel don't behave like that. 157 00:07:25.680 --> 00:07:28.519 If you push a soil embankment too hard, it doesn't 158 00:07:28.560 --> 00:07:32.680 bounce back, it yields it permanently deforms, and that permanent 159 00:07:32.720 --> 00:07:36.759 deformation is where we have to introduce failure criteria into 160 00:07:36.800 --> 00:07:37.199 the code. 161 00:07:37.319 --> 00:07:40.199 Let's get our hands dirty. Then, how does the code 162 00:07:40.240 --> 00:07:42.720 handle a material that is actively breaking? 163 00:07:42.879 --> 00:07:45.519 Well, it depends entirely on the material. For metals, the 164 00:07:45.519 --> 00:07:48.759 code might use the von Meses criterion, which looks at 165 00:07:48.800 --> 00:07:52.399 sheer stress. But for soils, strength is highly dependent on 166 00:07:52.439 --> 00:07:53.560 friction and confinement. 167 00:07:53.839 --> 00:07:56.959 Think about stepping on dry sand versus wet clay exactly. 168 00:07:57.120 --> 00:08:00.920 The code captures this using the more coolum fil criterion 169 00:08:01.199 --> 00:08:01.839 more coolim. 170 00:08:02.600 --> 00:08:05.639 We're looking at two main things here right, the friction angle, 171 00:08:05.680 --> 00:08:08.199 which is basically how steep you can pile dry sand 172 00:08:08.279 --> 00:08:12.959 before it slides, and cohesion, which is the internal stickiness 173 00:08:12.959 --> 00:08:14.199 of a material like clay. 174 00:08:14.399 --> 00:08:14.879 Spot on. 175 00:08:15.199 --> 00:08:18.399 But how does the code actually trigger a failure? Say 176 00:08:18.480 --> 00:08:20.680 I have a steep slope and I want to know 177 00:08:20.759 --> 00:08:23.680 its factor of safety, like how close it is to 178 00:08:23.720 --> 00:08:24.879 causing a landslide. 179 00:08:25.120 --> 00:08:29.519 So the software employs a strength reduction method. It systematically 180 00:08:29.560 --> 00:08:33.320 and incrementally reduces those soil strength parameters in the code, 181 00:08:33.360 --> 00:08:36.519 just dialing them down right. It artificially lowers the friction 182 00:08:36.679 --> 00:08:40.480 angle and the pohesion step by step recalculating the stresses 183 00:08:40.519 --> 00:08:43.679 each time. It keeps dropping those values until the digital 184 00:08:43.720 --> 00:08:46.960 model literally cannot find a state of equilibrium. 185 00:08:46.399 --> 00:08:49.519 Meaning the math breaks down. That displacement value shoot off 186 00:08:49.559 --> 00:08:53.240 to infinity, and our digital slope collapses exactly, and whatever 187 00:08:53.279 --> 00:08:55.320 amount we were able to reduce the strength before that 188 00:08:55.360 --> 00:08:58.759 collapse gives us our factor of safety. Here's where it 189 00:08:58.759 --> 00:09:01.559 gets really interesting to me though. Oh yeah, the mechanism 190 00:09:01.600 --> 00:09:04.200 of how the code handles the stress exactly at the 191 00:09:04.240 --> 00:09:05.519 moment the soil yields. 192 00:09:05.840 --> 00:09:09.120 Yes, this involves the viscoplastic strain method. 193 00:09:09.360 --> 00:09:10.279 Okay, what is that. 194 00:09:10.639 --> 00:09:13.879 Well, physical soil cannot sustain a stress higher than its 195 00:09:13.960 --> 00:09:17.440 ultimate strength. If a local patch of soil experiences a 196 00:09:17.480 --> 00:09:20.840 stress beyond its more Kulam limit, it would physically be 197 00:09:20.919 --> 00:09:24.440 accelerating into a landslide. The computer can't just leave that 198 00:09:24.480 --> 00:09:26.399 impossible stress sitting there in the matrix. 199 00:09:26.519 --> 00:09:29.799 I picture it like a bucket overflowing. Once the bucket 200 00:09:29.840 --> 00:09:32.840 is full, like once the soil has reached its maximum 201 00:09:32.919 --> 00:09:36.919 stress limit, any extra water or extra load has to 202 00:09:36.960 --> 00:09:37.720 go somewhere else. 203 00:09:38.039 --> 00:09:40.320 That's a great way to think about it. The viscoplastic 204 00:09:40.360 --> 00:09:43.320 algorithm acts like a pressure relief valve. It treats that 205 00:09:43.440 --> 00:09:47.159 excess stress as an error. Interesting, It calculates a corrective 206 00:09:47.159 --> 00:09:50.080 set of equivalent forces and applies them back into the 207 00:09:50.120 --> 00:09:54.080 system to redistribute that stress to neighboring elements that haven't 208 00:09:54.080 --> 00:09:58.879 failed yet. It safely returns those stray impossible stresses back 209 00:09:58.919 --> 00:09:59.960 to the failure surface. 210 00:10:00.080 --> 00:10:03.279 It's actively yielding. It pushes the load to the adjacent soil, 211 00:10:03.679 --> 00:10:06.399 and then that adjacent soil might fail and pass the 212 00:10:06.440 --> 00:10:08.919 load again until either the whole system finds a new 213 00:10:08.919 --> 00:10:10.399 balance or the whole trench. 214 00:10:10.120 --> 00:10:13.679 Colloxis exactly catching true geotechnical behavior. 215 00:10:13.519 --> 00:10:17.200 Which brings us to a huge practical application construction sequencing. 216 00:10:17.759 --> 00:10:20.799 If I'm building an embankment, I am stacking soil layer 217 00:10:20.840 --> 00:10:21.759 by layer, and. 218 00:10:21.679 --> 00:10:25.320 The code simulates that on banking process by activating elements 219 00:10:25.320 --> 00:10:28.519 in sequence, turning gravity on for each new layer as 220 00:10:28.519 --> 00:10:30.679 it gets added to mathematical mesh. 221 00:10:30.720 --> 00:10:33.960 But digging a trench like excavation is completely different. You 222 00:10:34.000 --> 00:10:37.279 are removing elements from the mesh, and as an engineer, 223 00:10:37.679 --> 00:10:40.759 you have to realize that excavation isn't just erasing data 224 00:10:40.799 --> 00:10:41.679 from a spreadsheet. 225 00:10:41.960 --> 00:10:44.519 No, not at all. When you remove a block of soil. 226 00:10:44.519 --> 00:10:47.679 In the program, you are removing the physical forces that 227 00:10:47.759 --> 00:10:50.399 block was exerting on the soil around it. You are 228 00:10:50.440 --> 00:10:52.639 taking away its weight and its confinement. 229 00:10:52.840 --> 00:10:54.919 Right, because dirt is heavy, very. 230 00:10:54.679 --> 00:10:57.799 Heavy, So the code has to actively apply unloading forces 231 00:10:57.840 --> 00:11:01.360 to the new boundary of your excavation. The ground relaxes, 232 00:11:01.480 --> 00:11:04.679 it heaves upward, the retaining walls bend inward. 233 00:11:04.919 --> 00:11:05.320 Wow. 234 00:11:05.399 --> 00:11:08.399 If your code doesn't account for that stress redistribution, your 235 00:11:08.399 --> 00:11:11.840 digital model will vastly underestimate the danger of a trench collapse. 236 00:11:12.039 --> 00:11:16.000 The text actually compares five different geometrical sequences just to 237 00:11:16.039 --> 00:11:17.720 simulate digging a vertical cut. 238 00:11:17.879 --> 00:11:21.039 That is wild. Okay, so we figured out static dirt 239 00:11:21.279 --> 00:11:25.720 and yielding dirt, but civil engineering is rarely that dryer. Still, 240 00:11:26.720 --> 00:11:29.840 what happens when we add water or when an earthquake. 241 00:11:29.519 --> 00:11:32.279 Hits we whilst structure is rarely an isolated system. If 242 00:11:32.279 --> 00:11:35.559 you build a heavy skyscraper on wet clay, the soil 243 00:11:35.639 --> 00:11:39.519 doesn't just squish instantly. The source material explores this through 244 00:11:39.559 --> 00:11:40.559 by it consolidation. 245 00:11:41.080 --> 00:11:43.240 Okay, think of the soil matrix like a sponge full 246 00:11:43.279 --> 00:11:46.120 of water. When you put a heavy weight on that sponge, 247 00:11:46.480 --> 00:11:49.320 the water in the pores takes all the stress initially 248 00:11:49.360 --> 00:11:53.159 because water doesn't really compress, but over time that poor 249 00:11:53.279 --> 00:11:57.279 water is squeezed out and the soil matrix slowly compresses down. 250 00:11:57.799 --> 00:12:00.480 To model that, the code has to couple the solid 251 00:12:00.519 --> 00:12:03.879 elasticity equations of the dirt with the fluid flow equations 252 00:12:03.879 --> 00:12:04.360 of the water. 253 00:12:04.480 --> 00:12:05.440 That sounds complicated. 254 00:12:05.519 --> 00:12:08.759 It is for soil that's usually Darcy's law. But if 255 00:12:08.759 --> 00:12:12.320 we are looking at complex fluid dynamics like water rushing 256 00:12:12.360 --> 00:12:15.039 through the spillway of that dam, the code moves into 257 00:12:15.080 --> 00:12:18.279 the Navier Stokes equations, which calculate the velocity and pressure 258 00:12:18.320 --> 00:12:20.759 of the fluid interacting with our structural mesh. 259 00:12:20.799 --> 00:12:25.000 And what about dynamic shaking, you know, wind loads or 260 00:12:25.120 --> 00:12:26.919 an earthquake tearing through the bedrock. 261 00:12:27.240 --> 00:12:30.559 Every physical structure, from a cantilever beam to a suspension 262 00:12:30.600 --> 00:12:33.240 bridge has natural modes of vibration. 263 00:12:33.120 --> 00:12:33.879 Like a tuning fork. 264 00:12:34.000 --> 00:12:37.799 Exactly like a tuning fork. If an earthquakes frequency aligns 265 00:12:37.840 --> 00:12:42.279 with one of those natural frequencies, the displacement amplifies, sometimes 266 00:12:42.320 --> 00:12:45.759 to the point of tearing the structure apart. To predict this, 267 00:12:46.279 --> 00:12:49.120 the code must find the structure's eigen values. 268 00:12:49.399 --> 00:12:53.679 But finding those natural frequencies requires isolating specific critical values 269 00:12:53.720 --> 00:12:57.879 the eigen values from that massive, unwieldy global matrix we 270 00:12:58.000 --> 00:12:58.679 talked about. 271 00:12:58.480 --> 00:13:01.519 Earlier, right, and the code uses algorithms like the lenxos 272 00:13:01.679 --> 00:13:04.320 or Arnuldy methods to do that. Think of them as 273 00:13:04.320 --> 00:13:07.720 mathematical shortcuts. Instead of trying to solve the entire giant 274 00:13:07.720 --> 00:13:11.120 matrix to find every single theoretical way a bridge could wiggle, 275 00:13:11.519 --> 00:13:14.840 these algorithms project the problem down into a much smaller, 276 00:13:15.080 --> 00:13:19.559 manageable version. They isolate just the few lowest, most critical 277 00:13:19.600 --> 00:13:22.159 resonant frequencies that actually threaten the structure. 278 00:13:22.399 --> 00:13:25.720 This raises an important question, though. If we are dealing 279 00:13:25.720 --> 00:13:28.639 with water squeezing out of a sponge over five years 280 00:13:28.919 --> 00:13:32.679 or an earthquake shaking a building over thirty seconds, how 281 00:13:32.759 --> 00:13:38.080 is time factored into these equations. Computers don't experience continuous time. 282 00:13:38.399 --> 00:13:41.080 That's a great point. We have to discritize time, just 283 00:13:41.120 --> 00:13:43.519 like we discritize the physical space of the dam. We 284 00:13:43.720 --> 00:13:46.519 chop the event into tiny time steps, right, and to 285 00:13:46.600 --> 00:13:50.080 integrate those steps, the code relies heavily on the Theta method. 286 00:13:50.240 --> 00:13:53.360 Time integration sounds like a delicate balancing act. What's the 287 00:13:53.440 --> 00:13:53.879 risk here? 288 00:13:54.440 --> 00:13:57.879 Well, generally have two choices. Explicit time integration is like 289 00:13:57.960 --> 00:13:59.919 driving a car by only looking in the rear view. 290 00:14:00.559 --> 00:14:02.960 It uses only the data from the past step to 291 00:14:03.000 --> 00:14:03.720 calculate the. 292 00:14:03.639 --> 00:14:05.720 Current step, which is fast, I assume. 293 00:14:05.519 --> 00:14:10.679 Computationally incredibly fast. Yeah, but if your time steps aren't 294 00:14:10.720 --> 00:14:15.279 infinitesimally tiny, the math quickly spirals out of control. Your 295 00:14:15.320 --> 00:14:17.759 simulation literally explodes with errors. 296 00:14:17.799 --> 00:14:20.000 Oh that's not good. So how does the THEATA method 297 00:14:20.080 --> 00:14:20.440 fix that. 298 00:14:20.759 --> 00:14:23.399 The implicit data method looks ahead. It looks at the 299 00:14:23.440 --> 00:14:26.519 current step and the future step simultaneously to find a balance. 300 00:14:26.879 --> 00:14:29.879 It requires solving a complex system of equations at every 301 00:14:29.879 --> 00:14:34.840 single time step, which makes it computationally much heavier and slower. However, 302 00:14:35.240 --> 00:14:38.480 it is unconditionally stable for a wide range of problems. 303 00:14:38.679 --> 00:14:40.879 You don't have to worry about your simulation crashing and 304 00:14:40.919 --> 00:14:44.399 burning just because your timestep was a millisecond too long. 305 00:14:44.840 --> 00:14:48.080 Another critical factor in dynamic analysis is how we tell 306 00:14:48.120 --> 00:14:51.559 the computer about the physical weight of the structure. The 307 00:14:51.600 --> 00:14:56.559 code contrasts lumped mass matrices with consistent mass matrices. 308 00:14:56.799 --> 00:14:58.879 Yeah, so if you have a twenty node brick element, 309 00:14:59.039 --> 00:15:01.320 a lumped mass matrix takes a total weight of that 310 00:15:01.399 --> 00:15:04.639 brick and simply divides it equally, treating it as point 311 00:15:04.679 --> 00:15:05.919 mass is sitting on the nodes. 312 00:15:06.159 --> 00:15:09.519 Imagine bowling balls connected by weightless springs exactly. 313 00:15:09.639 --> 00:15:12.639 It creates a very simple diagonal matrix, just a single 314 00:15:12.679 --> 00:15:15.399 column of numbers, which is blindingly fast for a computer 315 00:15:15.440 --> 00:15:16.000 to process. 316 00:15:16.159 --> 00:15:19.840 But a consistent mass matrix distributes the mass using the 317 00:15:19.919 --> 00:15:23.919 exact same continuous shape functions used for the stiffness. 318 00:15:23.480 --> 00:15:25.440 Right, it treats the element more like a block of 319 00:15:25.480 --> 00:15:29.080 solid jello. It creates a full complex matrix that couples 320 00:15:29.120 --> 00:15:30.159 the mass between. 321 00:15:29.840 --> 00:15:31.639 The nodes, which takes way more memory. 322 00:15:31.879 --> 00:15:34.960 It takes significantly more memory and processing power, but it 323 00:15:35.039 --> 00:15:37.840 is vastly more accurate for tracking how a stress wave 324 00:15:38.200 --> 00:15:42.120 like a seismic shock, actually propagates through a solid material. 325 00:15:42.559 --> 00:15:46.440 The trade off between accuracy and computational horsepower is the 326 00:15:46.480 --> 00:15:50.159 constant struggle of the finite element method, and that brings 327 00:15:50.240 --> 00:15:53.679 us to the ultimate ceiling. Sometimes, when our models of fluid, 328 00:15:53.759 --> 00:15:58.200 soil and shaking structures become overwhelmingly complex, a single desktop 329 00:15:58.240 --> 00:15:59.840 computer simply isn't going to cut it. 330 00:16:00.039 --> 00:16:03.080 Hush, definitely not. We have to scale up, moving from 331 00:16:03.159 --> 00:16:07.120 running codes serially on one processor to parallel processing across 332 00:16:07.240 --> 00:16:08.200 many processors. 333 00:16:08.399 --> 00:16:11.639 The source material illustrates this using a very specific, high 334 00:16:11.720 --> 00:16:15.120 stakes engineering challenge, the nuclear graphite brick yes. 335 00:16:15.440 --> 00:16:18.559 In advanced nuclear reactors, the core is often constructed from 336 00:16:18.639 --> 00:16:20.960 massive interlocking bricks of graphite, and. 337 00:16:20.960 --> 00:16:24.240 The text simulates a three D elastic solid using sixty 338 00:16:24.240 --> 00:16:27.279 four thousand elements for just a single graphite brick. This 339 00:16:27.440 --> 00:16:28.000 is amazing. 340 00:16:28.320 --> 00:16:32.759 It is because a real graphite brick is not perfectly uniform. 341 00:16:32.960 --> 00:16:37.840 It is manufactured, and it contains microscopic flaws. Its stiffness, 342 00:16:38.000 --> 00:16:42.120 its Young's modulus varies randomly throughout its entire volume. You 343 00:16:42.159 --> 00:16:45.279 cannot assign one single stiffness value to the whole block 344 00:16:45.559 --> 00:16:47.759 and expect an accurate safety assessment. 345 00:16:47.919 --> 00:16:50.799 So how do you test for random microscopic flaws. 346 00:16:51.039 --> 00:16:54.320 The engineering team runs a Monte Carlo style simulation. The 347 00:16:54.360 --> 00:16:59.080 program generates hundreds of different randomized stiffness distributions across those 348 00:16:59.159 --> 00:17:02.679 sixty four thousand elements, hundreds of them, hundreds, and it 349 00:17:02.759 --> 00:17:06.119 solves the thermal and physical stresses for every single variation 350 00:17:06.200 --> 00:17:09.079 to ensure the brick won't crack under worst case conditions. 351 00:17:09.200 --> 00:17:12.160 Running hundreds of sixty four thousand element models on a 352 00:17:12.200 --> 00:17:16.000 standard desktop would take months. It's totally unfeasible, which is. 353 00:17:15.920 --> 00:17:19.839 Why the code introduces MPI, or the message passing interface 354 00:17:19.920 --> 00:17:22.799 linking into cloud computing networks like Microsoft Azure. 355 00:17:22.880 --> 00:17:25.039 Think of it like building a massive jigsaw puzzle. If 356 00:17:25.039 --> 00:17:27.119 one person tries to do a sixty four thousand piece 357 00:17:27.119 --> 00:17:30.240 puzzle by themselves, it takes forever. But if you invite 358 00:17:30.240 --> 00:17:33.839 one hundred friends over hand, each person a specific corner 359 00:17:33.839 --> 00:17:37.200 of the puzzle and just have one person coordinating where 360 00:17:37.200 --> 00:17:39.599 the boundary edges meet, that's MPI. 361 00:17:39.960 --> 00:17:42.799 That is exactly what it is. The MPI code scatters 362 00:17:42.839 --> 00:17:45.839 the spatial domain of the graphite brick across dozens or 363 00:17:45.920 --> 00:17:49.319 hundreds of cloud processors. Processor one solves the top left 364 00:17:49.319 --> 00:17:52.480 corner using that element by element PCG solver we discussed. 365 00:17:52.799 --> 00:17:56.279 Processor two solves the bottom right and then then MPI 366 00:17:56.400 --> 00:17:59.480 manages the communication, gathering the results back together where those 367 00:17:59.519 --> 00:18:00.319 boundaries touch. 368 00:18:00.559 --> 00:18:05.319 It allows engineers to perform massive probabilistic risk assessments in 369 00:18:05.519 --> 00:18:09.039 hours instead of months. It opens up scales of analysis 370 00:18:09.079 --> 00:18:11.400 that were previously completely impossible. 371 00:18:11.480 --> 00:18:13.839 We have covered a tremendous amount of ground today. We 372 00:18:13.880 --> 00:18:17.440 started with a single simple Fortran subroutine acting as a 373 00:18:17.480 --> 00:18:20.079 digital lego block, and we scaled it all the way 374 00:18:20.160 --> 00:18:30.920 up to a massive parallel profits practice engineering. 375 00:18:31.400 --> 00:18:33.759 You aren't just a passive user clicking buttons on a 376 00:18:33.799 --> 00:18:34.920 commercial software. 377 00:18:34.599 --> 00:18:35.759 Package, not anymore. 378 00:18:35.839 --> 00:18:40.160 No, you understand that discretization, the mechanics of nonlinear yielding, 379 00:18:40.599 --> 00:18:43.880 the fluid dynamics, and the very real hardware limits of 380 00:18:43.920 --> 00:18:46.279 the machine sitting on your desk. Yeah, you control the 381 00:18:46.319 --> 00:18:47.480 physics now. 382 00:18:47.519 --> 00:18:50.240 As promised. For our learners out there, I want to 383 00:18:50.319 --> 00:18:53.920 leave you with a specific review exercise, directly inspired by 384 00:18:53.920 --> 00:18:57.039 the source text, to reinforce what we've covered about spatial 385 00:18:57.079 --> 00:18:58.920 discretization and stiffness. 386 00:18:58.960 --> 00:19:00.000 Oh awesome, let's hear it. 387 00:19:00.559 --> 00:19:03.960 Imagine a simple cantilever beam fixed at one end, free 388 00:19:04.000 --> 00:19:06.799 at the other, but it is resting entirely on an 389 00:19:06.839 --> 00:19:09.759 elastic foundation, like a beam sitting on a bed of springs. 390 00:19:09.799 --> 00:19:10.839 Okay, got it. Pictured. 391 00:19:11.039 --> 00:19:13.240 If you were to model this using just a single 392 00:19:13.400 --> 00:19:17.119 finite element of length L, with a flexial beam stiffness 393 00:19:17.119 --> 00:19:20.839 of ei and a foundation stiffness of K, how would 394 00:19:20.880 --> 00:19:23.319 you set up the matrix formulation to find the lowest 395 00:19:23.319 --> 00:19:24.039 buckling load. 396 00:19:24.319 --> 00:19:26.759 Get out a piece of paper and really try to 397 00:19:26.759 --> 00:19:29.759 write out how the structural stiffness matrix of the beam 398 00:19:30.039 --> 00:19:34.440 combines with the geometric stiffness of that underlying foundation. Thinking 399 00:19:34.480 --> 00:19:37.799 through the actual rows and columns will completely change how 400 00:19:37.839 --> 00:19:40.279 you view what your software is doing behind the scenes. 401 00:19:40.319 --> 00:19:43.079