WEBVTT 1 00:00:00.200 --> 00:00:03.359 Usually when we talk about making a diagnosis, there's this 2 00:00:03.439 --> 00:00:05.759 expectation of precision, you know what I mean. 3 00:00:05.679 --> 00:00:07.719 Oh, absolutely, Like you want a clear. 4 00:00:07.519 --> 00:00:10.720 Answer, right, if you suspect a broken arm, the doctor 5 00:00:10.759 --> 00:00:13.519 takes an X ray, points to that jagged white line 6 00:00:13.560 --> 00:00:17.399 on the film and gives you a definitive diagnosis. It's visible, 7 00:00:17.879 --> 00:00:20.480 categorical broken or not broken. 8 00:00:20.839 --> 00:00:24.600 And we really crave that binary clarity in engineering too. 9 00:00:25.000 --> 00:00:27.879 We want to see the crack in the concrete or 10 00:00:27.920 --> 00:00:30.399 the shear on the bolt. We want that physical evidence 11 00:00:30.399 --> 00:00:31.000 in front of us. 12 00:00:31.199 --> 00:00:33.920 But the second you step into the world of civil 13 00:00:34.079 --> 00:00:39.240 and structural simulations, suddenly that diagnostic X ray machine just shatters. 14 00:00:39.439 --> 00:00:41.280 It really does. It's completely different. 15 00:00:41.000 --> 00:00:44.000 Because if you are an engineering student, maybe a young professional, 16 00:00:44.119 --> 00:00:46.640 or just a self taught learner trying to master finite 17 00:00:46.679 --> 00:00:51.039 element analysis or FEA, you already know the universal truth here. 18 00:00:51.320 --> 00:00:55.719 Building a complex FEA model is deeply satisfying. But getting 19 00:00:55.759 --> 00:00:58.920 it to successfully converge without mathematically. 20 00:00:58.280 --> 00:01:01.399 Blowing up, Oh, It's an absolute nightmare, total nightmare. It's 21 00:01:01.439 --> 00:01:05.040 the literal definition of diagnostic muddy waters. I mean, you 22 00:01:05.120 --> 00:01:08.079 are sitting there staring at a screen filled with these 23 00:01:08.159 --> 00:01:14.439 chaotic red error messages just wondering why your beautifully constructed 24 00:01:14.560 --> 00:01:17.439 virtual bridge collapsed in the first, middle of second of 25 00:01:17.439 --> 00:01:18.560 the simulation. 26 00:01:18.280 --> 00:01:20.280 And the software doesn't give you a neat little X 27 00:01:20.359 --> 00:01:23.560 ray explaining why exactly it gives you nothing, which brings 28 00:01:23.640 --> 00:01:26.560 us to our mission for today's deep dive. We are 29 00:01:26.599 --> 00:01:32.439 tackling Rafael Jambald's massive, highly regarded book Troubleshooting Finite Element 30 00:01:32.519 --> 00:01:33.439 Modeling with. 31 00:01:33.439 --> 00:01:35.680 Aboquest the fantastic resource by the way. 32 00:01:35.640 --> 00:01:38.200 So good, and we are going to translate the dense 33 00:01:38.239 --> 00:01:41.840 theory of these like thousand page software manuals into a 34 00:01:42.000 --> 00:01:46.079 clear scientific survival guide for FAA. The goal is to 35 00:01:46.120 --> 00:01:50.799 decode those cryptic warnings, untangle mesh distortions, and really figure 36 00:01:50.799 --> 00:01:53.200 out how to stop the solver from just failing on you. 37 00:01:53.400 --> 00:01:56.200 Because abuqus is a powerhouse, you know, in the aerospace, 38 00:01:56.359 --> 00:02:00.000 civil and mechanical industries precisely because it can simulate almost 39 00:02:00.120 --> 00:02:01.519 any physical phenomenon right. 40 00:02:01.560 --> 00:02:02.760 It's incredibly capable. 41 00:02:02.959 --> 00:02:06.400 But that immense capability brings an overwhelming amount of documentation. 42 00:02:07.239 --> 00:02:11.800 And what BOLS provides is a structured methodology. Instead of 43 00:02:11.840 --> 00:02:16.159 wildly tweaking settings in a canic, he outlines a systematic 44 00:02:16.159 --> 00:02:18.599 way to diagnose the underlying physics of a failure. 45 00:02:18.759 --> 00:02:22.759 But before we even start dissecting specific error codes, Bulbs 46 00:02:22.800 --> 00:02:27.400 insists on stepping back right, like examining our initial approach 47 00:02:27.479 --> 00:02:28.280 to the simulation. 48 00:02:28.599 --> 00:02:31.759 Yeah, there is a foundational philosophy here. You cannot fix 49 00:02:31.759 --> 00:02:34.719 a mathematical solver if the physical logic you fet it 50 00:02:34.759 --> 00:02:36.919 is flawed from the very first click right. 51 00:02:37.000 --> 00:02:39.199 So this is what he calls the global mindset, which 52 00:02:39.240 --> 00:02:42.840 is grounded heavily in the Gigo principle garbage in, garbage out. 53 00:02:43.000 --> 00:02:45.599 Yes, in the world of FAA, it is a cardinal rule. 54 00:02:45.680 --> 00:02:48.680 The software is a mathematical engine. It just calculates whatever 55 00:02:48.680 --> 00:02:50.879 inputs it receives with ruthless perfection. 56 00:02:51.120 --> 00:02:55.039 So I picture it like programming a highly advanced, ultra 57 00:02:55.080 --> 00:02:58.319 precise industrial robot arm. If you tell the robot to 58 00:02:58.360 --> 00:03:01.680 move fifty feet to the left, will execute that command flawlessly, 59 00:03:01.879 --> 00:03:04.719 completely ignoring the fact that there's a solid concrete wall 60 00:03:04.759 --> 00:03:05.800 ten feet to its left. 61 00:03:06.120 --> 00:03:09.639 Exactly. It calculates the resulting crash perfectly based on the 62 00:03:09.719 --> 00:03:11.080 terrible instructions it was given. 63 00:03:11.280 --> 00:03:14.919 But with software used by major aerospace firms to design 64 00:03:15.000 --> 00:03:17.319 actual rockets, I mean it feels like there should be 65 00:03:17.319 --> 00:03:20.479 some kind of safeguard. Why doesn't the program just flag 66 00:03:20.520 --> 00:03:23.759 an input that defies basic structural logic. 67 00:03:23.879 --> 00:03:27.879 Because the software does not possess physical intuition. It really doesn't, 68 00:03:27.960 --> 00:03:30.680 no common sense, none at all. The mathematics used to 69 00:03:30.759 --> 00:03:33.800 solve a finite element model are entirely unique to the 70 00:03:33.840 --> 00:03:37.360 specific parameters you establish. The solver only knows the numbers 71 00:03:37.400 --> 00:03:40.080 in its matrix. So if you accidentally type in the 72 00:03:40.120 --> 00:03:43.919 density of a marshmallow for a steel ibeam, oh wow, Okay, yeah, 73 00:03:43.960 --> 00:03:46.960 the software doesn't know you're designing a skyscraper. It assumes 74 00:03:47.000 --> 00:03:49.719 you genuinely want to test the load bary capacity of 75 00:03:49.759 --> 00:03:50.840 a giant marshmallow. 76 00:03:51.000 --> 00:03:52.280 That's hilarious, and. 77 00:03:52.240 --> 00:03:56.439 It will give you a highly precise, beautifully colored, completely 78 00:03:56.560 --> 00:03:59.000 useless stress map of that marshmallow. 79 00:03:59.159 --> 00:04:01.879 So protecting ourselves else from the giant marshmallow beam requires 80 00:04:01.919 --> 00:04:06.240 groundwork before the software even opens. Bulb points to theoretical 81 00:04:06.240 --> 00:04:08.759 hand calculations as the absolute first step. 82 00:04:08.840 --> 00:04:11.719 Right, you have to do it. You must have a 83 00:04:11.759 --> 00:04:15.439 physical baseline before you build a complex three D mesh. 84 00:04:15.520 --> 00:04:18.360 You should be doing basic static calculations on paper, like 85 00:04:18.480 --> 00:04:22.279 what exactly, Well, if you're simulating a beam bending, use 86 00:04:22.279 --> 00:04:25.839 the classic flexure formula to find your expected bending stress, 87 00:04:26.399 --> 00:04:30.319 plot out your expected stress versus strain curve, verify your 88 00:04:30.360 --> 00:04:32.639 operating temperatures and design parameters. 89 00:04:32.759 --> 00:04:34.639 Just to have a Bullpark idea. 90 00:04:34.480 --> 00:04:37.879 Exactly, you need a rough estimate of the magnitude of 91 00:04:37.920 --> 00:04:40.720 your answer, so that when the software spits out a number, 92 00:04:41.160 --> 00:04:44.600 you have the context to recognize if it is mathematically 93 00:04:44.680 --> 00:04:46.560 accurate but physically absurd. 94 00:04:46.759 --> 00:04:49.160 Okay, so let's say we've done that homework, our baseline 95 00:04:49.240 --> 00:04:52.519 checks out, we build a geometry, assigned material properties, and 96 00:04:52.560 --> 00:04:53.199 we hit run. 97 00:04:53.439 --> 00:04:55.959 And this is where we hit the most notorious roadblock 98 00:04:56.000 --> 00:04:58.680 in all of FAA, the failure to converge. 99 00:04:59.000 --> 00:05:02.279 Yeah, the solver just loops and loops until it completely crashes. 100 00:05:02.439 --> 00:05:05.519 Right, So, convergence failure happens when the mathematical solver is 101 00:05:05.519 --> 00:05:09.600 trying to find an equilibrium state through iterative calculations and 102 00:05:09.639 --> 00:05:11.399 it simply cannot balance the equations. 103 00:05:11.560 --> 00:05:14.480 So the internal forces of your model just aren't matching 104 00:05:14.560 --> 00:05:15.879 the external forces you. 105 00:05:15.839 --> 00:05:19.439 Applied exactly, And this is when Abuquez throws out those 106 00:05:19.639 --> 00:05:21.480 terrifying cryptic warnings. 107 00:05:21.600 --> 00:05:23.560 Oh yeah, you look at the log file and you 108 00:05:23.600 --> 00:05:28.319 see a zero pivot warning or my personal favorite, time 109 00:05:28.360 --> 00:05:32.519 increment required is less than minimum. Those are classic to 110 00:05:32.560 --> 00:05:35.120 a lot of engineers, especially the beginners. Those just look 111 00:05:35.240 --> 00:05:36.759 like fatal computer glitches. 112 00:05:36.879 --> 00:05:39.879 But they aren't glitches at all. They are very specific 113 00:05:40.279 --> 00:05:41.639 mathematical cries for help. 114 00:05:41.720 --> 00:05:43.360 Okay, break that down for me. What is a zero 115 00:05:43.480 --> 00:05:44.959 pivot warning actually saying? 116 00:05:45.439 --> 00:05:48.839 Let's look at it mathematically? In finite element analysis, the 117 00:05:48.879 --> 00:05:54.079 software calculates displacement by solving a massive system of linear equations. 118 00:05:54.560 --> 00:05:58.879 It's essentially multiplying a stiffness matrix by a displacement factor 119 00:05:59.120 --> 00:05:59.879 to equal a four. 120 00:06:00.680 --> 00:06:01.879 Okay, tracking with you. 121 00:06:02.000 --> 00:06:04.399 So if a part of your model is completely unconstrained, 122 00:06:04.439 --> 00:06:06.600 say you know, you forgot to anchor a bolt, it 123 00:06:06.639 --> 00:06:08.360 has zero stiffness in that direction. 124 00:06:08.680 --> 00:06:11.399 So when the software tries to solve for displacement, it 125 00:06:11.480 --> 00:06:13.839 ends up trying to divide the applied force by zero. 126 00:06:14.240 --> 00:06:17.560 That is the exact mechanism. A zero pivot means the 127 00:06:17.600 --> 00:06:21.560 solver encounter to mathematical singularity. You asked it to divide 128 00:06:21.560 --> 00:06:25.160 by zero because your part is technically flying off into 129 00:06:25.199 --> 00:06:25.920 infinite space. 130 00:06:26.319 --> 00:06:29.040 That makes so much sense. What about the time increment 131 00:06:29.160 --> 00:06:30.480 less than minimum error? 132 00:06:30.560 --> 00:06:34.480 That operates on a similar principle of mathematical exhaustion. The 133 00:06:34.480 --> 00:06:38.319 physical system you created is so violently unstable that the 134 00:06:38.360 --> 00:06:43.120 software is desperately taking smaller and smaller mathematical time steps 135 00:06:43.519 --> 00:06:45.439 to try and capture the rapid deformation. 136 00:06:45.639 --> 00:06:46.680 Oh I see, yeah. 137 00:06:46.920 --> 00:06:50.000 Eventually the step size required hits the absolute floor limit 138 00:06:50.279 --> 00:06:52.240 and the solver just gives up. 139 00:06:52.279 --> 00:06:55.800 So these errors are basically symptoms of inadequate modeling, like 140 00:06:55.920 --> 00:06:58.720 conflicting boundary constraints or unstable. 141 00:06:58.199 --> 00:07:01.120 Physics exactly, which leads to one of the most critical 142 00:07:01.120 --> 00:07:04.360 troubleshooting strategies in the book. Never start with your final 143 00:07:04.519 --> 00:07:06.399 fully detailed CAD model. 144 00:07:06.560 --> 00:07:08.399 Yes, the light model approach. 145 00:07:08.519 --> 00:07:12.160 Building a light model first is non negotiable for complex simulations. 146 00:07:12.680 --> 00:07:15.519 Do not import a massive assembly with thousands of file AT's, 147 00:07:15.920 --> 00:07:20.560 nonlinear material, plasticity, friction, and complex contact dynamics all at once. 148 00:07:20.639 --> 00:07:21.800 You're just asking for trouble. 149 00:07:22.000 --> 00:07:26.199 You really are. Start with the most basic linear, stripped 150 00:07:26.199 --> 00:07:27.519 down version of your structure. 151 00:07:27.600 --> 00:07:29.839 But I can hear the pushback from the busy engineer 152 00:07:29.879 --> 00:07:33.600 listening right now, Because deadlines are incredibly tight in the 153 00:07:33.600 --> 00:07:38.240 real world, building a massive model piece by piece, running it, 154 00:07:38.480 --> 00:07:41.160 adding a piece and running it again. I mean that 155 00:07:41.279 --> 00:07:42.720 sounds wildly inefficient. 156 00:07:42.759 --> 00:07:44.040 I get that a lot, right. 157 00:07:44.079 --> 00:07:46.040 If you just run the full model and it crashes, 158 00:07:46.079 --> 00:07:48.600 can't you just look at the aero log and fix 159 00:07:48.720 --> 00:07:50.639 whatever specifically broke. 160 00:07:51.279 --> 00:07:55.120 Well, that approach is exactly how engineers lose entire weeks 161 00:07:55.160 --> 00:07:56.240 to a single simulation. 162 00:07:56.439 --> 00:07:57.959 Oh wow, really. 163 00:07:57.839 --> 00:08:01.079 Yeah, Because in a complex, finite element model, false flags 164 00:08:01.079 --> 00:08:04.160 are everywhere. A complex contact interaction failing on the right 165 00:08:04.199 --> 00:08:06.839 side of a bridge can cause a shockway of mathematical 166 00:08:06.839 --> 00:08:11.040 instability that registers as a zero pivot boundary error on 167 00:08:11.079 --> 00:08:13.319 the left side of the bridge. Oh man, So if 168 00:08:13.319 --> 00:08:15.600 you started with a heavy model, you will spend days 169 00:08:15.639 --> 00:08:19.759 troubleshooting a boundary condition that is actually perfectly fine. Isolating variables. 170 00:08:19.800 --> 00:08:22.360 By building up a light model ensures you know exactly 171 00:08:22.360 --> 00:08:24.439 which layer of complexity introduce the crash. 172 00:08:24.600 --> 00:08:28.279 So you're basically building a foundation of diagnostic trust precisely. 173 00:08:28.480 --> 00:08:31.800 And speaking of layers of complexity, even a light model 174 00:08:31.839 --> 00:08:35.759 needs loads applied to it to simulate anything, and Bolbs 175 00:08:35.919 --> 00:08:39.279 highlights a massive trap here regarding how we actually tell 176 00:08:39.279 --> 00:08:41.159 the software to apply those forces. 177 00:08:41.399 --> 00:08:44.639 This is a phenomenal technique for stabilizing a difficult model. 178 00:08:45.159 --> 00:08:49.840 Whenever possible, you should use displacement control rather than load control. 179 00:08:50.440 --> 00:08:52.559 Okay, walk us through the mechanics of that. Why does 180 00:08:52.559 --> 00:08:54.360 the software care how it gets pushed? 181 00:08:54.960 --> 00:08:58.759 Consider the math behind the solver's iterations. Let's use a 182 00:08:58.799 --> 00:09:02.960 simple steel rod being pulled intension. Under load control, you 183 00:09:03.039 --> 00:09:05.600 command the software to apply a heavy force, say one 184 00:09:05.679 --> 00:09:07.799 hundred thousand newtons, to the end of the rod. Okay, 185 00:09:08.120 --> 00:09:09.879 The software then has to figure out how far the 186 00:09:09.960 --> 00:09:12.519 rod stretches. As long as the steel is in its 187 00:09:12.519 --> 00:09:16.080 linear elastic phase, acting like a stiff spring, the math 188 00:09:16.159 --> 00:09:19.480 finds the answer easily. But if that force pushes the 189 00:09:19.519 --> 00:09:22.080 steel past its yield point, it becomes classic. 190 00:09:22.240 --> 00:09:26.200 The stiffness curve suddenly flattens out right. The material starts 191 00:09:26.240 --> 00:09:29.360 stretching dramatically under very little additional force. 192 00:09:29.399 --> 00:09:33.279 And that flat curve is mathematical cliff. The solver is 193 00:09:33.320 --> 00:09:36.799 trying to find where your massive force vector intersects with 194 00:09:36.879 --> 00:09:40.840 the material's internal stiffness curve. If the curve is flat, 195 00:09:41.120 --> 00:09:42.559 they might never intersect, so. 196 00:09:42.559 --> 00:09:45.559 The iteration diverges and the model crashes exactly. 197 00:09:45.799 --> 00:09:49.000 But with displacement control, you flip the script. You tell 198 00:09:49.000 --> 00:09:52.799 the software pull the end of this rod exactly five millimeters. 199 00:09:52.919 --> 00:09:55.840 Oh, so you are dictating the exact stopping point on 200 00:09:55.879 --> 00:09:56.879 the deformation graph. 201 00:09:57.039 --> 00:09:59.639 Yes, you force the solver to a specific point on 202 00:09:59.639 --> 00:10:03.000 the ex axis and it simply reads the corresponding force 203 00:10:03.039 --> 00:10:06.240 on the axis. It creates a much more stable incremental 204 00:10:06.240 --> 00:10:06.960 solution path. 205 00:10:07.120 --> 00:10:09.960 You're physically guiding the solver step by step. 206 00:10:09.759 --> 00:10:12.399 Completely avoiding the mathematical cliff of load control. 207 00:10:12.559 --> 00:10:16.360 That's brilliant. Okay, so let's move further down the troubleshooting pipeline. 208 00:10:16.879 --> 00:10:19.320 The inputs are logical, the light model is built, we're 209 00:10:19.360 --> 00:10:23.519 using displacement control, and the solver successfully reaches the finish line. 210 00:10:24.000 --> 00:10:27.279 We have convergence. Great feeling, but Bulbs warns that a 211 00:10:27.279 --> 00:10:30.399 converging model can still be a complete liar, especially when 212 00:10:30.399 --> 00:10:32.240 we look at the actual geometry of the mesh. 213 00:10:32.480 --> 00:10:36.759 Oh. Absolutely, The mesh is how we discritize a continuous 214 00:10:36.879 --> 00:10:42.240 physical object into solvable mathematical chunks, usually hexahedrals, which are 215 00:10:42.240 --> 00:10:45.960 basically three D bricks, or tetrahedrals, which are three D pyramids, 216 00:10:46.600 --> 00:10:50.759 and a running model can produce visually bizarre, totally non 217 00:10:50.799 --> 00:10:55.159 physical mesh shapes. If the mathematical formulation of those elements is. 218 00:10:55.159 --> 00:10:57.440 Wrong, which brings us to a phenomenon that just sounds 219 00:10:57.519 --> 00:11:01.399 terrifying to encounter hourglassing. Ah, Yes, you run your simulation 220 00:11:01.759 --> 00:11:05.600 and suddenly your smooth mesh looks like a wildly zigzagging accordion. 221 00:11:06.600 --> 00:11:08.840 What is actually happening inside the software to cause that? 222 00:11:09.120 --> 00:11:11.080 So to understand our glassing, we have to look at 223 00:11:11.080 --> 00:11:14.480 how an element calculates stress. It doesn't calculate stress everywhere 224 00:11:14.519 --> 00:11:17.600 inside itself. It evaluates it at specific internal locations called 225 00:11:17.679 --> 00:11:21.720 integration points. A fully integrated three D brick element has 226 00:11:21.799 --> 00:11:25.399 eight integration points. It's essentially watching the stress in the 227 00:11:25.399 --> 00:11:28.679 element from eight different camera angles. That sounds thorough it is, 228 00:11:28.879 --> 00:11:33.240 But those fully integrated elements are computationally heavy, and they 229 00:11:33.320 --> 00:11:36.720 often suffer from a problem called sheer locking, where the 230 00:11:36.759 --> 00:11:40.120 math makes them artificially stubbornly stiff during bending. 231 00:11:40.720 --> 00:11:44.200 So to save computational power and fix that locking issue, 232 00:11:44.320 --> 00:11:48.200 engineers often switch to reduced integration elements, which is. 233 00:11:48.200 --> 00:11:51.840 Where our glassing comes in. Because a reduced integration brick 234 00:11:51.919 --> 00:11:55.879 element only has a single integration point located dead center 235 00:11:55.879 --> 00:11:56.799 in the middle of the brick. 236 00:11:56.960 --> 00:11:59.279 It's like trying to determine what is happening in a 237 00:11:59.360 --> 00:12:02.240 large room by only looking through a tiny people right 238 00:12:02.279 --> 00:12:03.159 in the center of the door. 239 00:12:03.320 --> 00:12:05.679 That is a perfect way to visualize it. If that 240 00:12:05.759 --> 00:12:08.840 brick element is subjected to a pure bending force, the 241 00:12:08.879 --> 00:12:12.000 top might compress and the bottom might stretch, causing the 242 00:12:12.039 --> 00:12:15.279 brick to deform into a trapezoid. Right, But the dead 243 00:12:15.320 --> 00:12:18.120 center of that trapezoid, where our single people is doesn't 244 00:12:18.200 --> 00:12:21.000 change length at all. The strain at the integration point 245 00:12:21.039 --> 00:12:21.480 is zero. 246 00:12:21.639 --> 00:12:25.440 Oh, the math looks through the people, sees zero stress 247 00:12:25.720 --> 00:12:28.720 and just assumes the entire element is perfectly fine, even 248 00:12:28.759 --> 00:12:31.159 though the edges are warping wildly out of shape. 249 00:12:31.559 --> 00:12:36.799 Exactly, the element essentially has zero stiffness against that specific 250 00:12:36.840 --> 00:12:40.840 type of bending, and that deformation propagates through the entire 251 00:12:40.960 --> 00:12:44.360 mesh and the element stack into a zigzag pattern that 252 00:12:44.440 --> 00:12:45.960 looks like a series of hourglasses. 253 00:12:46.039 --> 00:12:48.320 So the math says it is an equilibrium. But the 254 00:12:48.320 --> 00:12:51.679 structural integrity of your simulation is completely ruined. 255 00:12:51.720 --> 00:12:52.679 It's totally ruined. 256 00:12:52.759 --> 00:12:55.759 And the fix for hourglassing isn't just ignoring it. You 257 00:12:55.840 --> 00:12:57.279 have to actively intervene. 258 00:12:57.679 --> 00:13:01.519 Yeah, you generally need to introduce artificial hourglass stiffness controls 259 00:13:01.519 --> 00:13:04.879 in the software refine the mesh significantly in areas of 260 00:13:04.960 --> 00:13:09.600 high bending, or strategically switch back to fully integrated elements 261 00:13:09.639 --> 00:13:11.679 where bending forces are critical. 262 00:13:11.720 --> 00:13:14.159 Get to know, and it is not just the geometric 263 00:13:14.200 --> 00:13:15.919 shape of the rush we have to watch right, it's 264 00:13:15.960 --> 00:13:18.279 the behavior of the material assigned to that mesh. 265 00:13:18.360 --> 00:13:18.600 Yes. 266 00:13:18.759 --> 00:13:22.080 Because Bolds points out that modeling material nonlinearity is a 267 00:13:22.159 --> 00:13:25.279 huge source of errors, especially with metals like steel, the. 268 00:13:25.279 --> 00:13:28.600 Software needs a highly accurate roadmap of what happens when 269 00:13:28.600 --> 00:13:33.120 a material permanently deforms in a standard stress strain curve. 270 00:13:33.200 --> 00:13:37.120 For steel, you have point A the limit of proportionality 271 00:13:37.120 --> 00:13:39.840 where the behavior stops being a straight line, and point 272 00:13:39.879 --> 00:13:42.840 B the true elastic limit where it permanently yields. 273 00:13:43.159 --> 00:13:45.840 So a major red flag in the abaqus log file 274 00:13:46.000 --> 00:13:50.720 is the excessive yielding warning. What actually triggers that. 275 00:13:50.080 --> 00:13:53.519 That warning fires when the current mathematical strain increment, which 276 00:13:53.559 --> 00:13:56.000 is the amount of stretch calculated in the tiny fraction 277 00:13:56.039 --> 00:13:59.399 of a second, exceeds the material's initial yield strain by 278 00:13:59.399 --> 00:14:00.759 a factor of five or more. 279 00:14:00.879 --> 00:14:03.799 So the software realizes that a structural steel beam just 280 00:14:03.960 --> 00:14:06.679 stretched like warm taffy in a single timestep. 281 00:14:06.799 --> 00:14:09.879 Yes, it is a clear indicator that either your applied 282 00:14:09.879 --> 00:14:12.840 loads are completely unreasonable, your boundary conditions failed and the 283 00:14:12.840 --> 00:14:16.000 part is flying away, or your material data table is 284 00:14:16.039 --> 00:14:18.080 incomplete and the software doesn't know how the steel is 285 00:14:18.080 --> 00:14:20.120 supposed to harden after yielding. 286 00:14:19.799 --> 00:14:24.120 And if you're simulating extreme bizarre physics that standard elements 287 00:14:24.159 --> 00:14:27.360 just cannot handle. Wolves actually discusses turning to the. 288 00:14:27.440 --> 00:14:32.519 UEL, right, Yes, the UEL the user element subroutine. This 289 00:14:32.679 --> 00:14:35.679 is essentially the nuclear option for advanced users. 290 00:14:35.519 --> 00:14:38.399 Because it allows you to write custom Fortran code to 291 00:14:38.440 --> 00:14:42.440 define the mathematical behavior of your own entirely novel finite 292 00:14:42.440 --> 00:14:43.480 elements exactly. 293 00:14:43.720 --> 00:14:47.240 It gives you incidite flexibility, but it requires a masterful 294 00:14:47.320 --> 00:14:51.799 understanding of the underlying finite element mathematics to execute correctly. 295 00:14:52.080 --> 00:14:55.279 Okay, so we have our mesh stabilized, our materials dialed in, 296 00:14:55.360 --> 00:14:58.759 and our elements behaving, but there is a massive threshold 297 00:14:58.799 --> 00:15:02.120 we still have to cross. What happens when two separate 298 00:15:02.200 --> 00:15:05.639 complex bodies in our simulation actually crash into each other? 299 00:15:05.840 --> 00:15:09.320 Contact analysis? Yeah, this is where a staggering number of 300 00:15:09.320 --> 00:15:10.919 simulations fall apart. 301 00:15:10.559 --> 00:15:13.919 Instantly, because in reality, contact is intuitive. You drop a 302 00:15:13.919 --> 00:15:15.840 hammer on a desk, and it stops when it hits 303 00:15:15.879 --> 00:15:18.519 the wood. But a computer has no concept of a 304 00:15:18.559 --> 00:15:22.360 solid surface. So how does FEA actually simulate two things 305 00:15:22.399 --> 00:15:25.120 touching without them just passing through each other like ghosts? 306 00:15:25.279 --> 00:15:28.679 It uses algorithms like the penalty method. In FEA, contact 307 00:15:28.720 --> 00:15:31.039 is not a solid wall. It is essentially an array 308 00:15:31.080 --> 00:15:34.799 of invisible, highly nonlinear springs placed between the nodes of 309 00:15:34.799 --> 00:15:35.679 the two surfaces. 310 00:15:35.879 --> 00:15:37.960 Invisible springs. Got it. 311 00:15:38.200 --> 00:15:41.440 You define a master surface, which is usually the stiffer body, 312 00:15:42.000 --> 00:15:44.200 and a slave surface which deforms against it. 313 00:15:44.320 --> 00:15:46.759 Bulbs provides a great visual in the book for this. 314 00:15:47.360 --> 00:15:50.759 Imagine a wooden cannilever beam anchored to a wall on 315 00:15:50.799 --> 00:15:54.320 the left, sticking out horizontally right. A downward force is 316 00:15:54.320 --> 00:15:57.600 applied near the wall. Farther down the beam. Underneath the 317 00:15:57.639 --> 00:16:01.399 tip is a rigid stone floor. That floor is our 318 00:16:01.399 --> 00:16:02.360 contact zone. 319 00:16:02.559 --> 00:16:06.159 Perfect so as the beam guns downward the tip approaches 320 00:16:06.200 --> 00:16:10.159 the floor, the software constantly calculates the clearance between the 321 00:16:10.200 --> 00:16:13.000 slave nodes on the beam and the master surface of 322 00:16:13.039 --> 00:16:16.639 the floor. Okay, as that distance approaches zero, the penalty 323 00:16:16.679 --> 00:16:20.200 method kicks in. The invisible springs between the surfaces suddenly 324 00:16:20.200 --> 00:16:24.960 generate an exponential resistive force. They become infinitely stiff to 325 00:16:24.960 --> 00:16:28.120 prevent the nodes from mathematically passing through the master surface. 326 00:16:28.279 --> 00:16:31.519 Wait, so we are essentially tricking the matrix equations. We're 327 00:16:31.519 --> 00:16:35.240 replacing a physical collision with mathematical springs that violently push 328 00:16:35.320 --> 00:16:36.960 back right at the moment of impact. 329 00:16:37.159 --> 00:16:38.360 That's exactly what we're doing. 330 00:16:38.440 --> 00:16:41.080 But why does this cause so many simulations to crash 331 00:16:41.080 --> 00:16:42.159 on the very first frame? 332 00:16:42.519 --> 00:16:46.799 Because of localized geometry problem called overclosure. If your CAD 333 00:16:46.919 --> 00:16:50.720 geometry isn't flawlessly aligned, a few slave nodes on the 334 00:16:50.720 --> 00:16:53.960 beam might mathematically overlap with the master surface of the 335 00:16:54.000 --> 00:16:56.440 floor before the simulation even begins. 336 00:16:56.559 --> 00:16:59.480 Oh, so the software boots up and thinks the beam 337 00:16:59.559 --> 00:17:02.519 is already magically embedded inside solid stone. 338 00:17:02.679 --> 00:17:06.960 Yes, at timestep zero, the penalty algorithm detects a negative clearance. 339 00:17:07.680 --> 00:17:11.880 Those invisible springs instantly register infinite stiffness and generate a 340 00:17:11.920 --> 00:17:16.119 restorative force so massive that it shatters the stiffness matrix. Wow, 341 00:17:16.200 --> 00:17:19.200 the solver immediately initiates a severe time cutback, and the 342 00:17:19.279 --> 00:17:22.720 job fails. To fix this, you have to manually adjust 343 00:17:22.759 --> 00:17:27.160 your initial contact parameters to resolve any overclosures, basically forcing 344 00:17:27.160 --> 00:17:29.519 those slave nos to lie perfectly flesh on the master 345 00:17:29.640 --> 00:17:31.519 surface before any force is applied. 346 00:17:31.839 --> 00:17:34.799 That is so delicate, But okay, even if you manage 347 00:17:34.799 --> 00:17:37.519 the geogo principle, you build a cautious light model, avoid 348 00:17:37.519 --> 00:17:41.799 the people trap of hourglassing, and flawlessly align your contact springs, 349 00:17:41.920 --> 00:17:43.920 you will eventually hit a wall. You can't figure out. 350 00:17:44.079 --> 00:17:45.680 It happens to everyone, right. 351 00:17:45.519 --> 00:17:47.680 So where does Bulbs point us? When the physics seem 352 00:17:47.759 --> 00:17:50.519 right but the model still fails, you turn to. 353 00:17:50.519 --> 00:17:55.319 The diagnostic toolbox and the documentation, and well, sometimes you 354 00:17:55.359 --> 00:17:58.000 have to accept that the issue isn't complex physics at all. 355 00:17:58.720 --> 00:18:00.680 Sometimes it's just basic. 356 00:18:00.400 --> 00:18:02.200 Syntax, like a typo in the matrix. 357 00:18:02.440 --> 00:18:06.079 Literally, a single missing comma after a data item and 358 00:18:06.119 --> 00:18:09.000 an input file can crash an entire job. You can 359 00:18:09.039 --> 00:18:13.079 spend a week questioning your understanding of nonlinear material plasticity, 360 00:18:13.519 --> 00:18:16.519 only to realize the software just couldn't read the text file. 361 00:18:16.680 --> 00:18:19.880 That is painfully relatable. But when you are truly stuck 362 00:18:19.920 --> 00:18:23.559 on the physics, Bulbs heavily advocates for a resource that 363 00:18:23.640 --> 00:18:25.680 I think a lot of engineers overlook because it seems 364 00:18:25.720 --> 00:18:28.920 too basic. And that's the built in a Backwiss guides. 365 00:18:28.599 --> 00:18:32.240 The verification benchmarks and example problems guides. They are an 366 00:18:32.319 --> 00:18:36.960 absolute gold mine. Software includes over five thousand highly documented 367 00:18:37.000 --> 00:18:38.720 basic test cases, and. 368 00:18:38.759 --> 00:18:41.759 Reading through the examples bowls highlights the sheer range of 369 00:18:41.759 --> 00:18:44.559 what you can simulate is staggering. I mean, they have 370 00:18:44.680 --> 00:18:48.359 pre built benchmark models for complex automotive brake squeal analysis. 371 00:18:48.440 --> 00:18:51.799 There's a model for rivet forming under extreme plastic deformation. 372 00:18:52.599 --> 00:18:56.400 They simulate a water filled bottle impacting the ground, and 373 00:18:56.480 --> 00:18:59.839 one of the most intense examples is in und X analysis, 374 00:19:00.000 --> 00:19:03.240 an underwater explosion acting on a detailed submarine Haull. 375 00:19:03.839 --> 00:19:06.480 The takeaway from those examples is that you rarely have 376 00:19:06.519 --> 00:19:08.799 to reinvent the wheel. If you are struggling to get 377 00:19:08.799 --> 00:19:11.599 a rubber seal to converge under pressure, or you can't 378 00:19:11.640 --> 00:19:15.960 get an explosive shock wave to propagate correctly, there is 379 00:19:16.079 --> 00:19:19.759 almost certainly a benchmark problem built into the documentation that 380 00:19:19.839 --> 00:19:21.319 mimics your scenario. 381 00:19:20.960 --> 00:19:22.319 So you don't have to start from scratch. 382 00:19:22.519 --> 00:19:25.680 Never you can pull up the verified input file examine 383 00:19:25.720 --> 00:19:28.839 exactly how the developers structure the mesh, define the materials 384 00:19:28.839 --> 00:19:31.640 and handle the contact springs, and just apply that architecture 385 00:19:31.680 --> 00:19:32.720 directly to your own model. 386 00:19:33.119 --> 00:19:36.440 We have covered a massive expanse of finite element theory today. 387 00:19:36.799 --> 00:19:39.920 If we distill this deep dive down to its absolute core, 388 00:19:40.440 --> 00:19:43.279 what is the ultimate philosophy the listener should walk away with. 389 00:19:43.680 --> 00:19:48.799 Successful simulation requires intense discipline. You must start with hand calculations. 390 00:19:49.000 --> 00:19:51.920 You must build complexity slowly with a light model. You 391 00:19:51.920 --> 00:19:55.720 should control displacement rather than load to stabilize the math. 392 00:19:56.319 --> 00:19:59.599 And most importantly, you have to understand the specific mathematical 393 00:19:59.599 --> 00:20:03.000 mechanic of the software, whether that is the single integration 394 00:20:03.079 --> 00:20:06.960 point causing an hourglass mesh or the penalty springs fighting 395 00:20:06.960 --> 00:20:07.720 an overclosure. 396 00:20:07.880 --> 00:20:10.240 Okay, let's put you the listener in the hot seat 397 00:20:10.279 --> 00:20:12.240 for a second to reinforce this. We always love a 398 00:20:12.240 --> 00:20:13.240 good review exercise. 399 00:20:13.319 --> 00:20:13.799 Let's do it. 400 00:20:14.319 --> 00:20:17.759 Imagine you were at your workstation. You're running a new 401 00:20:17.839 --> 00:20:22.119