Speaker 1: Right now, somewhere in the world, an engineer is staring
Speaker 1: at a computer screen.
Speaker 2: Yeah, probably looking at a beautifully colored three D model
Speaker 2: of a massive concrete dam or something.
Speaker 1: Exactly, and the screen lights up with these brilliant reassuring
Speaker 1: contours like red means high stress, blue means low stress.
Speaker 2: Right looks so clean, it.
Speaker 1: Does, And the software points at the graphic and essentially says,
Speaker 1: you know, the dam is perfectly safe, and it is
Speaker 1: incredibly tempting to just accept that. We like our engineering
Speaker 1: to be highly visible, neatly categorized, and safely handled by
Speaker 1: a computer.
Speaker 2: It feels clean, Yeah, it gives this a sense of
Speaker 2: absolute certainty. But underneath those pretty red and blue stress
Speaker 2: contours is a completely opaque mathematical black.
Speaker 1: Box, a total black box. Yeah.
Speaker 2: The moment you step out of that polished user interface
Speaker 2: and try to actually understand the mechanics of what the
Speaker 2: computer is doing to your digital structure, that certainty just
Speaker 2: it vanishes. You are looking at a computational landscape that
Speaker 2: is honestly pretty.
Speaker 1: Marked, and if that engineer doesn't know exactly how the
Speaker 1: computer is doing its math, that dam could fail in
Speaker 1: the real world despite what the pretty colors say absolutely,
Speaker 1: which is exactly why we are here today. Welcome to
Speaker 1: the deep dive. Whether you are an engineering student grinding
Speaker 1: through your first structural analysis course, a young professional trying
Speaker 1: to understand why your soil model just crashed at two
Speaker 1: in the morning, or a self taught learner who just
Speaker 1: has an insane curiosity about how massive things stand up
Speaker 1: and fall down, this is for you.
Speaker 2: We are going to be opening up that black box.
Speaker 1: Yes we are.
Speaker 2: Our mission today draws on a phenomenal source text. It's
Speaker 2: the fifth edition of Programming the Finite Element Method by
Speaker 2: I AM Smith, D. V. Griffiths, and L. Margets. The
Speaker 2: goal here is to bridge the massive gulf between understanding
Speaker 2: finite element theory on a classroom whiteboard and actually writing
Speaker 2: the computer programs to execute it.
Speaker 1: I am so excited to peek under the hood here.
Speaker 1: I mean, relying on commercial software is fine for basic,
Speaker 1: everyday tasks, but if you want to be a true
Speaker 1: master of civil engineering, you need to know exactly how
Speaker 1: that code interacts with physical dirt, flowing water, and yielding steel.
Speaker 1: We are going to translate dense matrix algebra into practical reality.
Speaker 2: Yeah, we're taking the jargon out of it exactly.
Speaker 1: But before we can model a massive skyscraper or a
Speaker 1: deep excavation site, we have to understand the fundamental materials
Speaker 1: of our software. We need to talk about the structure
Speaker 1: of the code itself.
Speaker 2: Well. The underlying architecture relies heavily on for trand two thousand.
Speaker 1: And eight, which sounds a bit retro.
Speaker 2: It does now. For trend might sound old school to
Speaker 2: you know one developers, but in the realm of heavy
Speaker 2: scientific matrix computation, it remains an absolute powerhouse. Oh wow, Yeah,
Speaker 2: the authors haven't written one giant, monolithic program that you
Speaker 2: just hit run on. They've actually built a library of
Speaker 2: over one hundred modular procedures.
Speaker 1: Okay, let's unpack this for a second. It's it's like
Speaker 1: digital legos.
Speaker 2: I love that analogy.
Speaker 1: Right, If you are building a model, you don't need
Speaker 1: to rein invent a custom mathematical operation every single time
Speaker 1: you want to multiply two massive matrices together. You just
Speaker 1: reach into the bucket, grab a pre compiled building block
Speaker 1: routine for matrix multiplication, and snap it into your main
Speaker 1: program exactly.
Speaker 2: And what's fascinating here is that modular approach gives you
Speaker 2: the engineer ultimate.
Speaker 1: Control because you aren't boxed in right.
Speaker 2: If you rely on closed source, proprietary software, you are
Speaker 2: trapped by their assumptions. You can only solve the specific
Speaker 2: problems their developers anticipated.
Speaker 1: Which is a huge limitation.
Speaker 2: It is by using fundamental building blocks you dictate the physics,
Speaker 2: and perhaps more importantly, this exact same logical architecture scales seamlessly.
Speaker 1: What do you mean by scales?
Speaker 2: Well, the physics of how a steel beam bends don't
Speaker 2: change whether you are running a simple one D test
Speaker 2: on a personal laptop or analyzing an entire suspension bridge
Speaker 2: on a massively parallel supercomputer.
Speaker 1: That makes total sense. So we have our digital lego blocks,
Speaker 1: but how do we use them to map out a
Speaker 1: continuous physical reality? I mean a jagged mountain face or
Speaker 1: a complex bolted connection. Isn't made of neat little blocks, No.
Speaker 2: They aren't. Mathematically, you cannot solve continuous differential equations for
Speaker 2: a complex random geometry. It's just impossible.
Speaker 1: What do we do?
Speaker 2: So we discritize. We take that continuous physical object and
Speaker 2: chop it up into a grid of localized, simplified pieces.
Speaker 2: Those are your finite element.
Speaker 1: Okay, and this all boils down to one fundamental formula
Speaker 1: that governs almost everything we were talking about today. Right,
Speaker 1: Stiffness times displacement equals force. That's the one. So if
Speaker 1: I push on something, how much does it move? Based
Speaker 1: on how stiff it is?
Speaker 2: Precisely, and the physical shape of those finite elements dictates
Speaker 2: how we calculate that stiffness. Okay, you might start with
Speaker 2: simple one D rods or two node beams for like
Speaker 2: a truss bridge. Then you move up to four node
Speaker 2: quadrilaterals for analyzing a flat concrete slab.
Speaker 1: Right, getting more complex?
Speaker 2: Yeah, And finally, for complex solid structures, you move up
Speaker 2: to twenty node hexahedra, which are basically sophisticated three.
Speaker 1: D bricks thood bricks.
Speaker 2: Got it? For each of these shapes, one of our
Speaker 2: digital Lego building blocks is a subroutine that numerically integrates
Speaker 2: its geometry to figure out its unique stiffness matrix.
Speaker 1: Wait, hold on, If we are chopping a massive dam
Speaker 1: into say one hundred thousand three D bricks, and we
Speaker 1: can calculate this stiffness for each brick, yeah, why can't
Speaker 1: we just take every single elements matrix grow them all
Speaker 1: together into one massive system wide global stiffness matrix and
Speaker 1: just solve the whole dam at once.
Speaker 2: So what does this all mean? In practice? That traditional
Speaker 2: approach is known as global assembly, and it works beautifully
Speaker 2: for one D frameworks or small two D.
Speaker 1: Problems, but not for the big stuff.
Speaker 2: No, if we connect this to the bigger picture, the
Speaker 2: physical reality of computer hardware catches up with you really fast.
Speaker 2: A matrix for one hundred thousand three D elements is gigantic.
Speaker 2: We're talking gigabytes maybe terabytes and size.
Speaker 1: Oh wow.
Speaker 2: And here is the kicker. The vast majority of that
Speaker 2: matrix is completely empty space. It's just zero.
Speaker 1: Wait why is it empty?
Speaker 2: Because a concrete node on the far left side of
Speaker 2: the dam doesn't directly interact with a node on the
Speaker 2: far right side.
Speaker 1: Oh okay, So if I try to assemble that globally,
Speaker 1: I'm forcing my computer to memorize millions of useless zeros. Exactly.
Speaker 1: I'll literally crash my work station trying to store empty space.
Speaker 1: So if we can't build one giant global matrix, how
Speaker 1: on earth do we solve the system.
Speaker 2: That's where we swap to an iterative approach. The book
Speaker 2: introduces something called an element by element technique or ebe
Speaker 2: relying on a preconditioned conjugate gradient solver a PCG right,
Speaker 2: a PCG. So, instead of building a giant matrix to
Speaker 2: solve all the simultaneous equations directly, the PCG solver calculates
Speaker 2: the necessary matrix vector products on the fly, one element
Speaker 2: at a time.
Speaker 1: That is so smart.
Speaker 2: It only keeps the local neighboring element matrices and memory,
Speaker 2: passing the forces back and forth until the whole system
Speaker 2: settles into a balanced answer.
Speaker 1: That is a brilliant workaround. We aren't just doing math.
Speaker 1: We are actively managing the physical memory limits of our
Speaker 1: computers to execute better maps for you, the listener. This
Speaker 1: is the difference between your soil model running in ten
Speaker 1: minutes so you can actually go home, versus blue screening
Speaker 1: your computer.
Speaker 2: It really is.
Speaker 1: But so far, this beautifully balanced MAB assumes our materials
Speaker 1: are perfectly elastic, like a rubber band. You pull a steel,
Speaker 1: it stretches, you let go, it snaps back perfectly.
Speaker 2: Yeah, but real dirt, concrete, and steel don't behave like that.
Speaker 2: If you push a soil embankment too hard, it doesn't
Speaker 2: bounce back, it yields it permanently deforms, and that permanent
Speaker 2: deformation is where we have to introduce failure criteria into
Speaker 2: the code.
Speaker 1: Let's get our hands dirty. Then, how does the code
Speaker 1: handle a material that is actively breaking?
Speaker 2: Well, it depends entirely on the material. For metals, the
Speaker 2: code might use the von Meses criterion, which looks at
Speaker 2: sheer stress. But for soils, strength is highly dependent on
Speaker 2: friction and confinement.
Speaker 1: Think about stepping on dry sand versus wet clay exactly.
Speaker 2: The code captures this using the more coolum fil criterion
Speaker 2: more coolim.
Speaker 1: We're looking at two main things here right, the friction angle,
Speaker 1: which is basically how steep you can pile dry sand
Speaker 1: before it slides, and cohesion, which is the internal stickiness
Speaker 1: of a material like clay.
Speaker 2: Spot on.
Speaker 1: But how does the code actually trigger a failure? Say
Speaker 1: I have a steep slope and I want to know
Speaker 1: its factor of safety, like how close it is to
Speaker 1: causing a landslide.
Speaker 2: So the software employs a strength reduction method. It systematically
Speaker 2: and incrementally reduces those soil strength parameters in the code,
Speaker 2: just dialing them down right. It artificially lowers the friction
Speaker 2: angle and the pohesion step by step recalculating the stresses
Speaker 2: each time. It keeps dropping those values until the digital
Speaker 2: model literally cannot find a state of equilibrium.
Speaker 1: Meaning the math breaks down. That displacement value shoot off
Speaker 1: to infinity, and our digital slope collapses exactly, and whatever
Speaker 1: amount we were able to reduce the strength before that
Speaker 1: collapse gives us our factor of safety. Here's where it
Speaker 1: gets really interesting to me though. Oh yeah, the mechanism
Speaker 1: of how the code handles the stress exactly at the
Speaker 1: moment the soil yields.
Speaker 2: Yes, this involves the viscoplastic strain method.
Speaker 1: Okay, what is that.
Speaker 2: Well, physical soil cannot sustain a stress higher than its
Speaker 2: ultimate strength. If a local patch of soil experiences a
Speaker 2: stress beyond its more Kulam limit, it would physically be
Speaker 2: accelerating into a landslide. The computer can't just leave that
Speaker 2: impossible stress sitting there in the matrix.
Speaker 1: I picture it like a bucket overflowing. Once the bucket
Speaker 1: is full, like once the soil has reached its maximum
Speaker 1: stress limit, any extra water or extra load has to
Speaker 1: go somewhere else.
Speaker 2: That's a great way to think about it. The viscoplastic
Speaker 2: algorithm acts like a pressure relief valve. It treats that
Speaker 2: excess stress as an error. Interesting, It calculates a corrective
Speaker 2: set of equivalent forces and applies them back into the
Speaker 2: system to redistribute that stress to neighboring elements that haven't
Speaker 2: failed yet. It safely returns those stray impossible stresses back
Speaker 2: to the failure surface.
Speaker 1: It's actively yielding. It pushes the load to the adjacent soil,
Speaker 1: and then that adjacent soil might fail and pass the
Speaker 1: load again until either the whole system finds a new
Speaker 1: balance or the whole trench.
Speaker 2: Colloxis exactly catching true geotechnical behavior.
Speaker 1: Which brings us to a huge practical application construction sequencing.
Speaker 1: If I'm building an embankment, I am stacking soil layer
Speaker 1: by layer, and.
Speaker 2: The code simulates that on banking process by activating elements
Speaker 2: in sequence, turning gravity on for each new layer as
Speaker 2: it gets added to mathematical mesh.
Speaker 1: But digging a trench like excavation is completely different. You
Speaker 1: are removing elements from the mesh, and as an engineer,
Speaker 1: you have to realize that excavation isn't just erasing data
Speaker 1: from a spreadsheet.
Speaker 2: No, not at all. When you remove a block of soil.
Speaker 2: In the program, you are removing the physical forces that
Speaker 2: block was exerting on the soil around it. You are
Speaker 2: taking away its weight and its confinement.
Speaker 1: Right, because dirt is heavy, very.
Speaker 2: Heavy, So the code has to actively apply unloading forces
Speaker 2: to the new boundary of your excavation. The ground relaxes,
Speaker 2: it heaves upward, the retaining walls bend inward.
Speaker 1: Wow.
Speaker 2: If your code doesn't account for that stress redistribution, your
Speaker 2: digital model will vastly underestimate the danger of a trench collapse.
Speaker 2: The text actually compares five different geometrical sequences just to
Speaker 2: simulate digging a vertical cut.
Speaker 1: That is wild. Okay, so we figured out static dirt
Speaker 1: and yielding dirt, but civil engineering is rarely that dryer. Still,
Speaker 1: what happens when we add water or when an earthquake.
Speaker 2: Hits we whilst structure is rarely an isolated system. If
Speaker 2: you build a heavy skyscraper on wet clay, the soil
Speaker 2: doesn't just squish instantly. The source material explores this through
Speaker 2: by it consolidation.
Speaker 1: Okay, think of the soil matrix like a sponge full
Speaker 1: of water. When you put a heavy weight on that sponge,
Speaker 1: the water in the pores takes all the stress initially
Speaker 1: because water doesn't really compress, but over time that poor
Speaker 1: water is squeezed out and the soil matrix slowly compresses down.
Speaker 2: To model that, the code has to couple the solid
Speaker 2: elasticity equations of the dirt with the fluid flow equations
Speaker 2: of the water.
Speaker 1: That sounds complicated.
Speaker 2: It is for soil that's usually Darcy's law. But if
Speaker 2: we are looking at complex fluid dynamics like water rushing
Speaker 2: through the spillway of that dam, the code moves into
Speaker 2: the Navier Stokes equations, which calculate the velocity and pressure
Speaker 2: of the fluid interacting with our structural mesh.
Speaker 1: And what about dynamic shaking, you know, wind loads or
Speaker 1: an earthquake tearing through the bedrock.
Speaker 2: Every physical structure, from a cantilever beam to a suspension
Speaker 2: bridge has natural modes of vibration.
Speaker 1: Like a tuning fork.
Speaker 2: Exactly like a tuning fork. If an earthquakes frequency aligns
Speaker 2: with one of those natural frequencies, the displacement amplifies, sometimes
Speaker 2: to the point of tearing the structure apart. To predict this,
Speaker 2: the code must find the structure's eigen values.
Speaker 1: But finding those natural frequencies requires isolating specific critical values
Speaker 1: the eigen values from that massive, unwieldy global matrix we
Speaker 1: talked about.
Speaker 2: Earlier, right, and the code uses algorithms like the lenxos
Speaker 2: or Arnuldy methods to do that. Think of them as
Speaker 2: mathematical shortcuts. Instead of trying to solve the entire giant
Speaker 2: matrix to find every single theoretical way a bridge could wiggle,
Speaker 2: these algorithms project the problem down into a much smaller,
Speaker 2: manageable version. They isolate just the few lowest, most critical
Speaker 2: resonant frequencies that actually threaten the structure.
Speaker 1: This raises an important question, though. If we are dealing
Speaker 1: with water squeezing out of a sponge over five years
Speaker 1: or an earthquake shaking a building over thirty seconds, how
Speaker 1: is time factored into these equations. Computers don't experience continuous time.
Speaker 2: That's a great point. We have to discritize time, just
Speaker 2: like we discritize the physical space of the dam. We
Speaker 2: chop the event into tiny time steps, right, and to
Speaker 2: integrate those steps, the code relies heavily on the Theta method.
Speaker 1: Time integration sounds like a delicate balancing act. What's the
Speaker 1: risk here?
Speaker 2: Well, generally have two choices. Explicit time integration is like
Speaker 2: driving a car by only looking in the rear view.
Speaker 2: It uses only the data from the past step to
Speaker 2: calculate the.
Speaker 1: Current step, which is fast, I assume.
Speaker 2: Computationally incredibly fast. Yeah, but if your time steps aren't
Speaker 2: infinitesimally tiny, the math quickly spirals out of control. Your
Speaker 2: simulation literally explodes with errors.
Speaker 1: Oh that's not good. So how does the THEATA method
Speaker 1: fix that.
Speaker 2: The implicit data method looks ahead. It looks at the
Speaker 2: current step and the future step simultaneously to find a balance.
Speaker 2: It requires solving a complex system of equations at every
Speaker 2: single time step, which makes it computationally much heavier and slower. However,
Speaker 2: it is unconditionally stable for a wide range of problems.
Speaker 2: You don't have to worry about your simulation crashing and
Speaker 2: burning just because your timestep was a millisecond too long.
Speaker 1: Another critical factor in dynamic analysis is how we tell
Speaker 1: the computer about the physical weight of the structure. The
Speaker 1: code contrasts lumped mass matrices with consistent mass matrices.
Speaker 2: Yeah, so if you have a twenty node brick element,
Speaker 2: a lumped mass matrix takes a total weight of that
Speaker 2: brick and simply divides it equally, treating it as point
Speaker 2: mass is sitting on the nodes.
Speaker 1: Imagine bowling balls connected by weightless springs exactly.
Speaker 2: It creates a very simple diagonal matrix, just a single
Speaker 2: column of numbers, which is blindingly fast for a computer
Speaker 2: to process.
Speaker 1: But a consistent mass matrix distributes the mass using the
Speaker 1: exact same continuous shape functions used for the stiffness.
Speaker 2: Right, it treats the element more like a block of
Speaker 2: solid jello. It creates a full complex matrix that couples
Speaker 2: the mass between.
Speaker 1: The nodes, which takes way more memory.
Speaker 2: It takes significantly more memory and processing power, but it
Speaker 2: is vastly more accurate for tracking how a stress wave
Speaker 2: like a seismic shock, actually propagates through a solid material.
Speaker 1: The trade off between accuracy and computational horsepower is the
Speaker 1: constant struggle of the finite element method, and that brings
Speaker 1: us to the ultimate ceiling. Sometimes, when our models of fluid,
Speaker 1: soil and shaking structures become overwhelmingly complex, a single desktop
Speaker 1: computer simply isn't going to cut it.
Speaker 2: Hush, definitely not. We have to scale up, moving from
Speaker 2: running codes serially on one processor to parallel processing across
Speaker 2: many processors.
Speaker 1: The source material illustrates this using a very specific, high
Speaker 1: stakes engineering challenge, the nuclear graphite brick yes.
Speaker 2: In advanced nuclear reactors, the core is often constructed from
Speaker 2: massive interlocking bricks of graphite, and.
Speaker 1: The text simulates a three D elastic solid using sixty
Speaker 1: four thousand elements for just a single graphite brick. This
Speaker 1: is amazing.
Speaker 2: It is because a real graphite brick is not perfectly uniform.
Speaker 2: It is manufactured, and it contains microscopic flaws. Its stiffness,
Speaker 2: its Young's modulus varies randomly throughout its entire volume. You
Speaker 2: cannot assign one single stiffness value to the whole block
Speaker 2: and expect an accurate safety assessment.
Speaker 1: So how do you test for random microscopic flaws.
Speaker 2: The engineering team runs a Monte Carlo style simulation. The
Speaker 2: program generates hundreds of different randomized stiffness distributions across those
Speaker 2: sixty four thousand elements, hundreds of them, hundreds, and it
Speaker 2: solves the thermal and physical stresses for every single variation
Speaker 2: to ensure the brick won't crack under worst case conditions.
Speaker 1: Running hundreds of sixty four thousand element models on a
Speaker 1: standard desktop would take months. It's totally unfeasible, which is.
Speaker 2: Why the code introduces MPI, or the message passing interface
Speaker 2: linking into cloud computing networks like Microsoft Azure.
Speaker 1: Think of it like building a massive jigsaw puzzle. If
Speaker 1: one person tries to do a sixty four thousand piece
Speaker 1: puzzle by themselves, it takes forever. But if you invite
Speaker 1: one hundred friends over hand, each person a specific corner
Speaker 1: of the puzzle and just have one person coordinating where
Speaker 1: the boundary edges meet, that's MPI.
Speaker 2: That is exactly what it is. The MPI code scatters
Speaker 2: the spatial domain of the graphite brick across dozens or
Speaker 2: hundreds of cloud processors. Processor one solves the top left
Speaker 2: corner using that element by element PCG solver we discussed.
Speaker 2: Processor two solves the bottom right and then then MPI
Speaker 2: manages the communication, gathering the results back together where those
Speaker 2: boundaries touch.
Speaker 1: It allows engineers to perform massive probabilistic risk assessments in
Speaker 1: hours instead of months. It opens up scales of analysis
Speaker 1: that were previously completely impossible.
Speaker 2: We have covered a tremendous amount of ground today. We
Speaker 2: started with a single simple Fortran subroutine acting as a
Speaker 2: digital lego block, and we scaled it all the way
Speaker 2: up to a massive parallel profits practice engineering.
Speaker 1: You aren't just a passive user clicking buttons on a
Speaker 1: commercial software.
Speaker 2: Package, not anymore.
Speaker 1: No, you understand that discretization, the mechanics of nonlinear yielding,
Speaker 1: the fluid dynamics, and the very real hardware limits of
Speaker 1: the machine sitting on your desk. Yeah, you control the
Speaker 1: physics now.
Speaker 2: As promised. For our learners out there, I want to
Speaker 2: leave you with a specific review exercise, directly inspired by
Speaker 2: the source text, to reinforce what we've covered about spatial
Speaker 2: discretization and stiffness.
Speaker 1: Oh awesome, let's hear it.
Speaker 2: Imagine a simple cantilever beam fixed at one end, free
Speaker 2: at the other, but it is resting entirely on an
Speaker 2: elastic foundation, like a beam sitting on a bed of springs.
Speaker 1: Okay, got it. Pictured.
Speaker 2: If you were to model this using just a single
Speaker 2: finite element of length L, with a flexial beam stiffness
Speaker 2: of ei and a foundation stiffness of K, how would
Speaker 2: you set up the matrix formulation to find the lowest
Speaker 2: buckling load.
Speaker 1: Get out a piece of paper and really try to
Speaker 1: write out how the structural stiffness matrix of the beam
Speaker 1: combines with the geometric stiffness of that underlying foundation. Thinking
Speaker 1: through the actual rows and columns will completely change how
Speaker 1: you view what your software is doing behind the scenes.
Speaker 2: It really forces you to connect the physical reality to
Speaker 2: the math it does.
Speaker 1: And I'll leave you with one final provocative thought to ponder.
Speaker 1: If we can currently use parallel processing and cloud computing
Speaker 1: to model the random microscopic variations in a single graphite brick. Yeah,
Speaker 1: how close are we to building real time digital twins
Speaker 1: of entire cities? Imagine a cloud simulation where every steel beam,
Speaker 1: every water pipe, and every soil layer under a major
Speaker 1: metropolis is being computed simultaneously, reacting to weather and traffic
Speaker 1: in real time, predicting infrastructure failures before a single crack
Speaker 1: ever appears.
Speaker 2: That level of predictive modeling is the absolute frontier of
Speaker 2: civil engineer.
Speaker 1: The black box isn't something to avoid anymore. It's the
Speaker 1: key to building the future. Keep learning, keep questioning the math,
Speaker 1: and we'll see you on the next deep dive.