Speaker 1: Usually when we talk about making a diagnosis, there's this
Speaker 1: expectation of precision, you know what I mean.
Speaker 2: Oh, absolutely, Like you want a clear.
Speaker 1: Answer, right, if you suspect a broken arm, the doctor
Speaker 1: takes an X ray, points to that jagged white line
Speaker 1: on the film and gives you a definitive diagnosis. It's visible,
Speaker 1: categorical broken or not broken.
Speaker 2: And we really crave that binary clarity in engineering too.
Speaker 2: We want to see the crack in the concrete or
Speaker 2: the shear on the bolt. We want that physical evidence
Speaker 2: in front of us.
Speaker 1: But the second you step into the world of civil
Speaker 1: and structural simulations, suddenly that diagnostic X ray machine just shatters.
Speaker 2: It really does. It's completely different.
Speaker 1: Because if you are an engineering student, maybe a young professional,
Speaker 1: or just a self taught learner trying to master finite
Speaker 1: element analysis or FEA, you already know the universal truth here.
Speaker 1: Building a complex FEA model is deeply satisfying. But getting
Speaker 1: it to successfully converge without mathematically.
Speaker 2: Blowing up, Oh, It's an absolute nightmare, total nightmare. It's
Speaker 2: the literal definition of diagnostic muddy waters. I mean, you
Speaker 2: are sitting there staring at a screen filled with these
Speaker 2: chaotic red error messages just wondering why your beautifully constructed
Speaker 2: virtual bridge collapsed in the first, middle of second of
Speaker 2: the simulation.
Speaker 1: And the software doesn't give you a neat little X
Speaker 1: ray explaining why exactly it gives you nothing, which brings
Speaker 1: us to our mission for today's deep dive. We are
Speaker 1: tackling Rafael Jambald's massive, highly regarded book Troubleshooting Finite Element
Speaker 1: Modeling with.
Speaker 2: Aboquest the fantastic resource by the way.
Speaker 1: So good, and we are going to translate the dense
Speaker 1: theory of these like thousand page software manuals into a
Speaker 1: clear scientific survival guide for FAA. The goal is to
Speaker 1: decode those cryptic warnings, untangle mesh distortions, and really figure
Speaker 1: out how to stop the solver from just failing on you.
Speaker 2: Because abuqus is a powerhouse, you know, in the aerospace,
Speaker 2: civil and mechanical industries precisely because it can simulate almost
Speaker 2: any physical phenomenon right.
Speaker 1: It's incredibly capable.
Speaker 2: But that immense capability brings an overwhelming amount of documentation.
Speaker 2: And what BOLS provides is a structured methodology. Instead of
Speaker 2: wildly tweaking settings in a canic, he outlines a systematic
Speaker 2: way to diagnose the underlying physics of a failure.
Speaker 1: But before we even start dissecting specific error codes, Bulbs
Speaker 1: insists on stepping back right, like examining our initial approach
Speaker 1: to the simulation.
Speaker 2: Yeah, there is a foundational philosophy here. You cannot fix
Speaker 2: a mathematical solver if the physical logic you fet it
Speaker 2: is flawed from the very first click right.
Speaker 1: So this is what he calls the global mindset, which
Speaker 1: is grounded heavily in the Gigo principle garbage in, garbage out.
Speaker 2: Yes, in the world of FAA, it is a cardinal rule.
Speaker 2: The software is a mathematical engine. It just calculates whatever
Speaker 2: inputs it receives with ruthless perfection.
Speaker 1: So I picture it like programming a highly advanced, ultra
Speaker 1: precise industrial robot arm. If you tell the robot to
Speaker 1: move fifty feet to the left, will execute that command flawlessly,
Speaker 1: completely ignoring the fact that there's a solid concrete wall
Speaker 1: ten feet to its left.
Speaker 2: Exactly. It calculates the resulting crash perfectly based on the
Speaker 2: terrible instructions it was given.
Speaker 1: But with software used by major aerospace firms to design
Speaker 1: actual rockets, I mean it feels like there should be
Speaker 1: some kind of safeguard. Why doesn't the program just flag
Speaker 1: an input that defies basic structural logic.
Speaker 2: Because the software does not possess physical intuition. It really doesn't,
Speaker 2: no common sense, none at all. The mathematics used to
Speaker 2: solve a finite element model are entirely unique to the
Speaker 2: specific parameters you establish. The solver only knows the numbers
Speaker 2: in its matrix. So if you accidentally type in the
Speaker 2: density of a marshmallow for a steel ibeam, oh wow, Okay, yeah,
Speaker 2: the software doesn't know you're designing a skyscraper. It assumes
Speaker 2: you genuinely want to test the load bary capacity of
Speaker 2: a giant marshmallow.
Speaker 1: That's hilarious, and.
Speaker 2: It will give you a highly precise, beautifully colored, completely
Speaker 2: useless stress map of that marshmallow.
Speaker 1: So protecting ourselves else from the giant marshmallow beam requires
Speaker 1: groundwork before the software even opens. Bulb points to theoretical
Speaker 1: hand calculations as the absolute first step.
Speaker 2: Right, you have to do it. You must have a
Speaker 2: physical baseline before you build a complex three D mesh.
Speaker 2: You should be doing basic static calculations on paper, like
Speaker 2: what exactly, Well, if you're simulating a beam bending, use
Speaker 2: the classic flexure formula to find your expected bending stress,
Speaker 2: plot out your expected stress versus strain curve, verify your
Speaker 2: operating temperatures and design parameters.
Speaker 1: Just to have a Bullpark idea.
Speaker 2: Exactly, you need a rough estimate of the magnitude of
Speaker 2: your answer, so that when the software spits out a number,
Speaker 2: you have the context to recognize if it is mathematically
Speaker 2: accurate but physically absurd.
Speaker 1: Okay, so let's say we've done that homework, our baseline
Speaker 1: checks out, we build a geometry, assigned material properties, and
Speaker 1: we hit run.
Speaker 2: And this is where we hit the most notorious roadblock
Speaker 2: in all of FAA, the failure to converge.
Speaker 1: Yeah, the solver just loops and loops until it completely crashes.
Speaker 2: Right, So, convergence failure happens when the mathematical solver is
Speaker 2: trying to find an equilibrium state through iterative calculations and
Speaker 2: it simply cannot balance the equations.
Speaker 1: So the internal forces of your model just aren't matching
Speaker 1: the external forces you.
Speaker 2: Applied exactly, And this is when Abuquez throws out those
Speaker 2: terrifying cryptic warnings.
Speaker 1: Oh yeah, you look at the log file and you
Speaker 1: see a zero pivot warning or my personal favorite, time
Speaker 1: increment required is less than minimum. Those are classic to
Speaker 1: a lot of engineers, especially the beginners. Those just look
Speaker 1: like fatal computer glitches.
Speaker 2: But they aren't glitches at all. They are very specific
Speaker 2: mathematical cries for help.
Speaker 1: Okay, break that down for me. What is a zero
Speaker 1: pivot warning actually saying?
Speaker 2: Let's look at it mathematically? In finite element analysis, the
Speaker 2: software calculates displacement by solving a massive system of linear equations.
Speaker 2: It's essentially multiplying a stiffness matrix by a displacement factor
Speaker 2: to equal a four.
Speaker 1: Okay, tracking with you.
Speaker 2: So if a part of your model is completely unconstrained,
Speaker 2: say you know, you forgot to anchor a bolt, it
Speaker 2: has zero stiffness in that direction.
Speaker 1: So when the software tries to solve for displacement, it
Speaker 1: ends up trying to divide the applied force by zero.
Speaker 2: That is the exact mechanism. A zero pivot means the
Speaker 2: solver encounter to mathematical singularity. You asked it to divide
Speaker 2: by zero because your part is technically flying off into
Speaker 2: infinite space.
Speaker 1: That makes so much sense. What about the time increment
Speaker 1: less than minimum error?
Speaker 2: That operates on a similar principle of mathematical exhaustion. The
Speaker 2: physical system you created is so violently unstable that the
Speaker 2: software is desperately taking smaller and smaller mathematical time steps
Speaker 2: to try and capture the rapid deformation.
Speaker 1: Oh I see, yeah.
Speaker 2: Eventually the step size required hits the absolute floor limit
Speaker 2: and the solver just gives up.
Speaker 1: So these errors are basically symptoms of inadequate modeling, like
Speaker 1: conflicting boundary constraints or unstable.
Speaker 2: Physics exactly, which leads to one of the most critical
Speaker 2: troubleshooting strategies in the book. Never start with your final
Speaker 2: fully detailed CAD model.
Speaker 1: Yes, the light model approach.
Speaker 2: Building a light model first is non negotiable for complex simulations.
Speaker 2: Do not import a massive assembly with thousands of file AT's,
Speaker 2: nonlinear material, plasticity, friction, and complex contact dynamics all at once.
Speaker 1: You're just asking for trouble.
Speaker 2: You really are. Start with the most basic linear, stripped
Speaker 2: down version of your structure.
Speaker 1: But I can hear the pushback from the busy engineer
Speaker 1: listening right now, Because deadlines are incredibly tight in the
Speaker 1: real world, building a massive model piece by piece, running it,
Speaker 1: adding a piece and running it again. I mean that
Speaker 1: sounds wildly inefficient.
Speaker 2: I get that a lot, right.
Speaker 1: If you just run the full model and it crashes,
Speaker 1: can't you just look at the aero log and fix
Speaker 1: whatever specifically broke.
Speaker 2: Well, that approach is exactly how engineers lose entire weeks
Speaker 2: to a single simulation.
Speaker 1: Oh wow, really.
Speaker 2: Yeah, Because in a complex, finite element model, false flags
Speaker 2: are everywhere. A complex contact interaction failing on the right
Speaker 2: side of a bridge can cause a shockway of mathematical
Speaker 2: instability that registers as a zero pivot boundary error on
Speaker 2: the left side of the bridge. Oh man, So if
Speaker 2: you started with a heavy model, you will spend days
Speaker 2: troubleshooting a boundary condition that is actually perfectly fine. Isolating variables.
Speaker 2: By building up a light model ensures you know exactly
Speaker 2: which layer of complexity introduce the crash.
Speaker 1: So you're basically building a foundation of diagnostic trust precisely.
Speaker 1: And speaking of layers of complexity, even a light model
Speaker 1: needs loads applied to it to simulate anything, and Bolbs
Speaker 1: highlights a massive trap here regarding how we actually tell
Speaker 1: the software to apply those forces.
Speaker 2: This is a phenomenal technique for stabilizing a difficult model.
Speaker 2: Whenever possible, you should use displacement control rather than load control.
Speaker 1: Okay, walk us through the mechanics of that. Why does
Speaker 1: the software care how it gets pushed?
Speaker 2: Consider the math behind the solver's iterations. Let's use a
Speaker 2: simple steel rod being pulled intension. Under load control, you
Speaker 2: command the software to apply a heavy force, say one
Speaker 2: hundred thousand newtons, to the end of the rod. Okay,
Speaker 2: The software then has to figure out how far the
Speaker 2: rod stretches. As long as the steel is in its
Speaker 2: linear elastic phase, acting like a stiff spring, the math
Speaker 2: finds the answer easily. But if that force pushes the
Speaker 2: steel past its yield point, it becomes classic.
Speaker 1: The stiffness curve suddenly flattens out right. The material starts
Speaker 1: stretching dramatically under very little additional force.
Speaker 2: And that flat curve is mathematical cliff. The solver is
Speaker 2: trying to find where your massive force vector intersects with
Speaker 2: the material's internal stiffness curve. If the curve is flat,
Speaker 2: they might never intersect, so.
Speaker 1: The iteration diverges and the model crashes exactly.
Speaker 2: But with displacement control, you flip the script. You tell
Speaker 2: the software pull the end of this rod exactly five millimeters.
Speaker 1: Oh, so you are dictating the exact stopping point on
Speaker 1: the deformation graph.
Speaker 2: Yes, you force the solver to a specific point on
Speaker 2: the ex axis and it simply reads the corresponding force
Speaker 2: on the axis. It creates a much more stable incremental
Speaker 2: solution path.
Speaker 1: You're physically guiding the solver step by step.
Speaker 2: Completely avoiding the mathematical cliff of load control.
Speaker 1: That's brilliant. Okay, so let's move further down the troubleshooting pipeline.
Speaker 1: The inputs are logical, the light model is built, we're
Speaker 1: using displacement control, and the solver successfully reaches the finish line.
Speaker 1: We have convergence. Great feeling, but Bulbs warns that a
Speaker 1: converging model can still be a complete liar, especially when
Speaker 1: we look at the actual geometry of the mesh.
Speaker 2: Oh. Absolutely, The mesh is how we discritize a continuous
Speaker 2: physical object into solvable mathematical chunks, usually hexahedrals, which are
Speaker 2: basically three D bricks, or tetrahedrals, which are three D pyramids,
Speaker 2: and a running model can produce visually bizarre, totally non
Speaker 2: physical mesh shapes. If the mathematical formulation of those elements is.
Speaker 1: Wrong, which brings us to a phenomenon that just sounds
Speaker 1: terrifying to encounter hourglassing. Ah, Yes, you run your simulation
Speaker 1: and suddenly your smooth mesh looks like a wildly zigzagging accordion.
Speaker 1: What is actually happening inside the software to cause that?
Speaker 2: So to understand our glassing, we have to look at
Speaker 2: how an element calculates stress. It doesn't calculate stress everywhere
Speaker 2: inside itself. It evaluates it at specific internal locations called
Speaker 2: integration points. A fully integrated three D brick element has
Speaker 2: eight integration points. It's essentially watching the stress in the
Speaker 2: element from eight different camera angles. That sounds thorough it is,
Speaker 2: But those fully integrated elements are computationally heavy, and they
Speaker 2: often suffer from a problem called sheer locking, where the
Speaker 2: math makes them artificially stubbornly stiff during bending.
Speaker 1: So to save computational power and fix that locking issue,
Speaker 1: engineers often switch to reduced integration elements, which is.
Speaker 2: Where our glassing comes in. Because a reduced integration brick
Speaker 2: element only has a single integration point located dead center
Speaker 2: in the middle of the brick.
Speaker 1: It's like trying to determine what is happening in a
Speaker 1: large room by only looking through a tiny people right
Speaker 1: in the center of the door.
Speaker 2: That is a perfect way to visualize it. If that
Speaker 2: brick element is subjected to a pure bending force, the
Speaker 2: top might compress and the bottom might stretch, causing the
Speaker 2: brick to deform into a trapezoid. Right, But the dead
Speaker 2: center of that trapezoid, where our single people is doesn't
Speaker 2: change length at all. The strain at the integration point
Speaker 2: is zero.
Speaker 1: Oh, the math looks through the people, sees zero stress
Speaker 1: and just assumes the entire element is perfectly fine, even
Speaker 1: though the edges are warping wildly out of shape.
Speaker 2: Exactly, the element essentially has zero stiffness against that specific
Speaker 2: type of bending, and that deformation propagates through the entire
Speaker 2: mesh and the element stack into a zigzag pattern that
Speaker 2: looks like a series of hourglasses.
Speaker 1: So the math says it is an equilibrium. But the
Speaker 1: structural integrity of your simulation is completely ruined.
Speaker 2: It's totally ruined.
Speaker 1: And the fix for hourglassing isn't just ignoring it. You
Speaker 1: have to actively intervene.
Speaker 2: Yeah, you generally need to introduce artificial hourglass stiffness controls
Speaker 2: in the software refine the mesh significantly in areas of
Speaker 2: high bending, or strategically switch back to fully integrated elements
Speaker 2: where bending forces are critical.
Speaker 1: Get to know, and it is not just the geometric
Speaker 1: shape of the rush we have to watch right, it's
Speaker 1: the behavior of the material assigned to that mesh.
Speaker 2: Yes.
Speaker 1: Because Bolds points out that modeling material nonlinearity is a
Speaker 1: huge source of errors, especially with metals like steel, the.
Speaker 2: Software needs a highly accurate roadmap of what happens when
Speaker 2: a material permanently deforms in a standard stress strain curve.
Speaker 2: For steel, you have point A the limit of proportionality
Speaker 2: where the behavior stops being a straight line, and point
Speaker 2: B the true elastic limit where it permanently yields.
Speaker 1: So a major red flag in the abaqus log file
Speaker 1: is the excessive yielding warning. What actually triggers that.
Speaker 2: That warning fires when the current mathematical strain increment, which
Speaker 2: is the amount of stretch calculated in the tiny fraction
Speaker 2: of a second, exceeds the material's initial yield strain by
Speaker 2: a factor of five or more.
Speaker 1: So the software realizes that a structural steel beam just
Speaker 1: stretched like warm taffy in a single timestep.
Speaker 2: Yes, it is a clear indicator that either your applied
Speaker 2: loads are completely unreasonable, your boundary conditions failed and the
Speaker 2: part is flying away, or your material data table is
Speaker 2: incomplete and the software doesn't know how the steel is
Speaker 2: supposed to harden after yielding.
Speaker 1: And if you're simulating extreme bizarre physics that standard elements
Speaker 1: just cannot handle. Wolves actually discusses turning to the.
Speaker 2: UEL, right, Yes, the UEL the user element subroutine. This
Speaker 2: is essentially the nuclear option for advanced users.
Speaker 1: Because it allows you to write custom Fortran code to
Speaker 1: define the mathematical behavior of your own entirely novel finite
Speaker 1: elements exactly.
Speaker 2: It gives you incidite flexibility, but it requires a masterful
Speaker 2: understanding of the underlying finite element mathematics to execute correctly.
Speaker 1: Okay, so we have our mesh stabilized, our materials dialed in,
Speaker 1: and our elements behaving, but there is a massive threshold
Speaker 1: we still have to cross. What happens when two separate
Speaker 1: complex bodies in our simulation actually crash into each other?
Speaker 2: Contact analysis? Yeah, this is where a staggering number of
Speaker 2: simulations fall apart.
Speaker 1: Instantly, because in reality, contact is intuitive. You drop a
Speaker 1: hammer on a desk, and it stops when it hits
Speaker 1: the wood. But a computer has no concept of a
Speaker 1: solid surface. So how does FEA actually simulate two things
Speaker 1: touching without them just passing through each other like ghosts?
Speaker 2: It uses algorithms like the penalty method. In FEA, contact
Speaker 2: is not a solid wall. It is essentially an array
Speaker 2: of invisible, highly nonlinear springs placed between the nodes of
Speaker 2: the two surfaces.
Speaker 1: Invisible springs. Got it.
Speaker 2: You define a master surface, which is usually the stiffer body,
Speaker 2: and a slave surface which deforms against it.
Speaker 1: Bulbs provides a great visual in the book for this.
Speaker 1: Imagine a wooden cannilever beam anchored to a wall on
Speaker 1: the left, sticking out horizontally right. A downward force is
Speaker 1: applied near the wall. Farther down the beam. Underneath the
Speaker 1: tip is a rigid stone floor. That floor is our
Speaker 1: contact zone.
Speaker 2: Perfect so as the beam guns downward the tip approaches
Speaker 2: the floor, the software constantly calculates the clearance between the
Speaker 2: slave nodes on the beam and the master surface of
Speaker 2: the floor. Okay, as that distance approaches zero, the penalty
Speaker 2: method kicks in. The invisible springs between the surfaces suddenly
Speaker 2: generate an exponential resistive force. They become infinitely stiff to
Speaker 2: prevent the nodes from mathematically passing through the master surface.
Speaker 1: Wait, so we are essentially tricking the matrix equations. We're
Speaker 1: replacing a physical collision with mathematical springs that violently push
Speaker 1: back right at the moment of impact.
Speaker 2: That's exactly what we're doing.
Speaker 1: But why does this cause so many simulations to crash
Speaker 1: on the very first frame?
Speaker 2: Because of localized geometry problem called overclosure. If your CAD
Speaker 2: geometry isn't flawlessly aligned, a few slave nodes on the
Speaker 2: beam might mathematically overlap with the master surface of the
Speaker 2: floor before the simulation even begins.
Speaker 1: Oh, so the software boots up and thinks the beam
Speaker 1: is already magically embedded inside solid stone.
Speaker 2: Yes, at timestep zero, the penalty algorithm detects a negative clearance.
Speaker 2: Those invisible springs instantly register infinite stiffness and generate a
Speaker 2: restorative force so massive that it shatters the stiffness matrix. Wow,
Speaker 2: the solver immediately initiates a severe time cutback, and the
Speaker 2: job fails. To fix this, you have to manually adjust
Speaker 2: your initial contact parameters to resolve any overclosures, basically forcing
Speaker 2: those slave nos to lie perfectly flesh on the master
Speaker 2: surface before any force is applied.
Speaker 1: That is so delicate, But okay, even if you manage
Speaker 1: the geogo principle, you build a cautious light model, avoid
Speaker 1: the people trap of hourglassing, and flawlessly align your contact springs,
Speaker 1: you will eventually hit a wall. You can't figure out.
Speaker 2: It happens to everyone, right.
Speaker 1: So where does Bulbs point us? When the physics seem
Speaker 1: right but the model still fails, you turn to.
Speaker 2: The diagnostic toolbox and the documentation, and well, sometimes you
Speaker 2: have to accept that the issue isn't complex physics at all.
Speaker 2: Sometimes it's just basic.
Speaker 1: Syntax, like a typo in the matrix.
Speaker 2: Literally, a single missing comma after a data item and
Speaker 2: an input file can crash an entire job. You can
Speaker 2: spend a week questioning your understanding of nonlinear material plasticity,
Speaker 2: only to realize the software just couldn't read the text file.
Speaker 1: That is painfully relatable. But when you are truly stuck
Speaker 1: on the physics, Bulbs heavily advocates for a resource that
Speaker 1: I think a lot of engineers overlook because it seems
Speaker 1: too basic. And that's the built in a Backwiss guides.
Speaker 2: The verification benchmarks and example problems guides. They are an
Speaker 2: absolute gold mine. Software includes over five thousand highly documented
Speaker 2: basic test cases, and.
Speaker 1: Reading through the examples bowls highlights the sheer range of
Speaker 1: what you can simulate is staggering. I mean, they have
Speaker 1: pre built benchmark models for complex automotive brake squeal analysis.
Speaker 1: There's a model for rivet forming under extreme plastic deformation.
Speaker 1: They simulate a water filled bottle impacting the ground, and
Speaker 1: one of the most intense examples is in und X analysis,
Speaker 1: an underwater explosion acting on a detailed submarine Haull.
Speaker 2: The takeaway from those examples is that you rarely have
Speaker 2: to reinvent the wheel. If you are struggling to get
Speaker 2: a rubber seal to converge under pressure, or you can't
Speaker 2: get an explosive shock wave to propagate correctly, there is
Speaker 2: almost certainly a benchmark problem built into the documentation that
Speaker 2: mimics your scenario.
Speaker 1: So you don't have to start from scratch.
Speaker 2: Never you can pull up the verified input file examine
Speaker 2: exactly how the developers structure the mesh, define the materials
Speaker 2: and handle the contact springs, and just apply that architecture
Speaker 2: directly to your own model.
Speaker 1: We have covered a massive expanse of finite element theory today.
Speaker 1: If we distill this deep dive down to its absolute core,
Speaker 1: what is the ultimate philosophy the listener should walk away with.
Speaker 2: Successful simulation requires intense discipline. You must start with hand calculations.
Speaker 2: You must build complexity slowly with a light model. You
Speaker 2: should control displacement rather than load to stabilize the math.
Speaker 2: And most importantly, you have to understand the specific mathematical
Speaker 2: mechanic of the software, whether that is the single integration
Speaker 2: point causing an hourglass mesh or the penalty springs fighting
Speaker 2: an overclosure.
Speaker 1: Okay, let's put you the listener in the hot seat
Speaker 1: for a second to reinforce this. We always love a
Speaker 1: good review exercise.
Speaker 2: Let's do it.
Speaker 1: Imagine you were at your workstation. You're running a new
Speaker 1: simulation of a structural steel beam under heavy tension. The
Speaker 1: solver fails in the very first increment, throwing a zero
Speaker 1: pivot warning. You look at the visualization and the mesh
Speaker 1: is warped into a bizarre zigzagging pattern.
Speaker 2: Interesting scenario based.
Speaker 1: On the mechanics we just explored, what two immediate changes
Speaker 1: should you make to that model before running it again.
Speaker 2: Well, consider the underlying mechanisms a zero pivot under heavy
Speaker 2: tension and a zigzagging mesh.
Speaker 1: Right, if you were tracking with the math, you know
Speaker 1: exactly what to do. First, to stabilize that tension and
Speaker 1: avoid the mathematical cliff, switch your model from load control
Speaker 1: to displacement control. And second, to fix that zigzagging mesh
Speaker 1: you're looking at hourglass. You need to switch away from
Speaker 1: reduced integration elements in that bending zone or refine the
Speaker 1: mesh so the integration points can accurately capture the stress.
Speaker 2: It is entirely about seeing past the warning label and
Speaker 2: diagnosing the math.
Speaker 1: This has been such a revealing look into the hidden,
Speaker 1: chaotic architecture of FEA. And to wrap up today's deep dive,
Speaker 1: I really want to leave you with something to consider
Speaker 1: about your own workflow.
Speaker 2: We open by comparing finite element analysis to an X
Speaker 2: ray machine. But as we have seen, it is not
Speaker 2: a camera taking a snapshot of reality. Yeah, it is
Speaker 2: an incredibly sophisticated calculator.
Speaker 1: It's a powerful oracle. It can calculate the exact plastic
Speaker 1: strain on a submarine hall during an underwater explosion down
Speaker 1: to the fifth decimal point. But it has zero common sense.
Speaker 1: It doesn't know what a submarine is, it doesn't know
Speaker 1: water from concrete. It only knows the numbers you feed
Speaker 1: into its matrix.
Speaker 2: Which means the true value of a civil or structural
Speaker 2: engineer is not found in knowing how to navigate a
Speaker 2: software interface. The true value is having the deep physical
Speaker 2: intuition to know exactly when the machine is lying to you.
Speaker 1: So the next time you sit down at your workstation
Speaker 1: and a brilliantly colored, flawless looking stress map renders on
Speaker 1: your screen, take a step back. Ask yourself, how much
Speaker 1: are you relying on your own hard earned engineering intuition
Speaker 1: and how much are you just blindly trusting the math
Speaker 1: on the screen in front of you.