The wing before the name

A month ago I wrote about Ray Clough’s failed summer of 1952 at Boeing. He spent three months trying to model a delta wing with beams, went home without a solution, came back the next year, and eight years later gave the world the phrase “finite element method.” Many of you told me that first summer was the part that stayed with you.

But that story leaves two people in the shadows.

The first is the man who invited Clough to Seattle and, the following summer, suggested the idea that unlocked the problem: Jon Turner. Without Turner there is no Boeing summer program for Clough, no delta wing, and no 1956 paper.

The second never set foot in that Boeing office. In London, a Greek engineer who had escaped Nazi Germany was building his own road to the same destination, starting from energy principles rather than from a specific wing. His name was John Argyris.

Every solver you run today rests on what these two men did in the 1950s. Most analysts I meet cannot name either of them. This article is an attempt to change that, and to ask what their stories say about our work now.

Seattle: Jon Turner and the wing that would not behave

M. Jonathan Turner was born in Oakville, Indiana, in 1915, and was fascinated by airplanes from boyhood. By the early 1950s he led the Structural Dynamics Unit at Boeing in Seattle, and he had a problem that classical methods could not solve.

High-performance military aircraft were moving to delta and swept wings. These were thin, low aspect ratio structures that behaved more like plates than beams. Beam theory, which had served straight wings well for decades, could not predict how they would vibrate. Boeing had even built a fairly large delta wing model to measure its vibration properties, and the analysis could not match it.

Turner’s first move was organizational, not mathematical. Through Boeing’s summer faculty program, he brought in Ray Clough from UC Berkeley and Harold Martin from the University of Washington. Clough later recalled spending the summer of 1952 trying to adapt an existing procedure to the delta wing, the problem that eventually led to the finite element method. The beams failed. In 1953, Turner proposed modeling the wing as two-dimensional plate elements connected at their corners.

What Turner did next is the part history usually skips.

He presented it before it was polished. Turner showed the Boeing work at the January 1954 meeting of the Institute of the Aeronautical Sciences in New York. The paper itself, “Stiffness and Deflection Analysis of Complex Structures” by Turner, Clough, Martin and Topp, did not appear until September 1956, in the Journal of the Aeronautical Sciences, Vol. 23, No. 9.

He built it for the computer. The procedure was designed from the start to be programmed: compute each element’s stiffness, add them into a global matrix, solve. That assembly by direct addition is what we now call the direct stiffness method. In 1959, Turner published a further paper presenting it explicitly as an efficient approach for computer implementation.

He sold it inside Boeing. Turner convinced the company to commit resources to the method. The payoff came a decade later: the Boeing 747, introduced in 1969, was the first major commercial aircraft analyzed extensively with finite elements.

In their own history of early FEM research, Clough and Ed Wilson give Turner principal credit for the 1956 work. Turner died in 1995 at the age of 80. His Seattle Times obituary described a quiet, meditative engineer. A former colleague said the computer-aided design of the 777 still rested on the fundamentals Turner developed.

London: John Argyris and the energy theorems

Argyris took a very different road. He was born Johann Hadjiargyris on 19 August 1913 in Volos, Greece, about 300 km north of Athens. He was educated in Athens, studied civil engineering there and in Munich, and graduated with distinction from the Munich Technical University in 1936.

His early professional work was on guyed masts for radio antennas, which were multiplying across Europe in the 1930s. According to Karl-Eugen Kurrer’s history of structural theory, Argyris showed that the wind load perpendicular to the plane usually considered also had to be checked. Remember that detail. It is the instinct of an analyst who asks about the load case nobody else is running.

Then came the war. Argyris was imprisoned in Germany and escaped; accounts say he swam the Rhine during an air raid to reach Switzerland. He completed his doctorate in aeronautics at ETH Zurich in 1942, and in 1943 moved to England as a technical officer in the Engineering Department of the Royal Aeronautical Society. Part of that work was done as a member of a secret commission, which is one reason so little of it was visible at the time.

Kurrer states that as early as August 1943, Argyris had developed triangular elements for the analysis of swept-back wings. That claim deserves caution, since the wartime work was not published openly. But it places him on the same problem as Turner, a decade earlier and an ocean away.

In 1949 Argyris joined Imperial College London as a senior lecturer, becoming a full professor in 1955. Between 1954 and 1955 he published a long series titled “Energy Theorems and Structural Analysis” in the journal Aircraft Engineering, drawn from his Imperial College lectures. The first installments appeared in late 1954 and already extended the energy principles to temperature effects and nonlinear stress-strain relations. The series was later republished as a book with Sydney Kelsey in 1960.

What the series did was systematize how the elemental components of a structure are assembled into a single system of equations, grounding it all in energy principles and matrix algebra. Force methods and displacement methods appeared as two expressions of one framework rather than rival techniques.

In 1959 Argyris took a joint appointment at Stuttgart, where he directed an institute for aerospace structures and built a campus around digital computing. The ASKA program developed under his direction became the model for many later industrial codes. In 1970 he founded the journal Computer Methods in Applied Mechanics and Engineering, still one of the field’s leading publications. He was elected a Fellow of the Royal Society in 1986 and died in Stuttgart on 2 April 2004, aged 90.

Two roads to the same matrix

Turner came to the method from a problem. Argyris came to it from a principle. Both arrived at a structure assembled from elements, expressed as matrices, and solved by computer.

Turner had a specific wing, test data to compare against, and a company that needed answers. He wanted a procedure simple enough that a computer could run it on real aircraft. Argyris wanted a theory general enough to describe any structure as an assembly of parts whose behavior follows from energy.

Neither was complete alone. Carlos Felippa, a former student of Clough, framed this period as a play in three acts. The first act belongs to the 1930s matrix pioneers Collar and Duncan. The second is a period of confusion, when matrix methods grew complicated in response to competing demands. In the third, the direct stiffness method arrived and cleaned it all up, turning matrix structural analysis into the finite element method we use now. Argyris and Turner are the two central figures of that story.

The synthesis is visible in every modern solver. The element formulation owes much to the energy-based thinking Argyris systematized. The assembly, element by element into a global stiffness matrix, is Turner’s direct stiffness method. When you mesh a part and press solve, you are using both.

Why history forgot them

The method has more than two parents, and two of them are well remembered. In 1943, the mathematician Richard Courant solved a torsion problem using simple functions defined over triangular subdomains, a primitive form of the finite element method a decade before Boeing. From the 1960s, Olgierd Zienkiewicz carried the method far beyond aircraft and, in 1967, published the first textbook dedicated to it. Mathematicians cite Courant, and generations of engineers learned FEM from Zienkiewicz.

Turner and Argyris stand between them in time, and receive far less of the credit.

If both men mattered so much, why does the popular story start with Clough? I see three reasons, and none of them is about the quality of the work.

The name wins.

Clough coined “finite element method” in 1960, and a good name travels further than a good paper. Before that, everyone was speaking the language of matrix and direct stiffness methods. Once the field had a name, its history was told around the person who gave it.

Industry does not write textbooks.

Turner spent his career at Boeing. His results lived in internal programs and aircraft designs, and the engineers he trained were Boeing engineers, not graduate students publishing under his name. Academic pioneers build schools that keep their story alive. Industrial pioneers build airplanes.

Secrecy and language.

Part of Argyris’s early work was done under wartime secrecy. His published work was highly mathematical, and his later career centered in Stuttgart. In the English-speaking world, the history of FEM was largely written from the Berkeley side.

There is a lesson here for anyone who builds methods quietly inside a company or a project team. The work can outlive the name unless someone takes the time to write the history down. Clough did that for Turner, in print, decades later.

What Turner and Argyris teach analysts today

History is only useful if it changes how we work on Monday morning. Here is what I take from these two careers.

Start from the structure, not from the tool.

Clough’s beams failed in 1952 because a delta wing does not carry load like a beam. Turner’s plate elements worked because they matched how the structure actually behaves. Before choosing an element type, ask what the structure is really doing. The most sophisticated solver cannot rescue the wrong idealization.

Theory and practice need each other.

Turner without Argyris gives you a procedure that works but may not generalize. Argyris without Turner gives you an elegant framework that may never reach a production aircraft. The best analysts I know carry both: they understand the energy principles behind an element, and they know how it behaves on a real part with real boundary conditions.

Validate against something physical.

Turner’s team had a delta wing model and vibration measurements to compare against. That is what made the method credible inside Boeing. Seventy years later, the principle has not changed. A model that has never been checked against a test, a hand calculation, or a trusted reference is a hypothesis, not a result.

Ask about the load case nobody is running.

Argyris’s early work on radio masts came down to checking a wind direction others assumed did not matter. Every analyst should have that reflex. Many of the failures we study began with a case that was never analyzed.

Name the people behind your tools, and in your own team.

Clough gave Turner principal credit in his own account, and that generosity is part of why we can tell this story at all. In your team, credit the person who suggested the idea that unlocked the problem, even when someone else wrote the report.

The tools have changed beyond recognition since 1956. Turner and Argyris worked on early computers with a tiny fraction of the memory in your phone. But the questions they asked are exactly the ones we still face: What is this structure really doing? Is my model telling me the truth? How do I know?

The next time you assemble a global stiffness matrix with a single click, take a second to remember the quiet engineer in Seattle and the Greek émigré in London who taught us how.

Further reading

• Turner, M. J., Clough, R. W., Martin, H. C. and Topp, L. J. (1956). Stiffness and Deflection Analysis of Complex Structures. Journal of the Aeronautical Sciences, 23(9), 805-823.

• Clough, R. W. and Wilson, E. L. (1999). Early Finite Element Research at Berkeley.

• Argyris, J. H. (1954). Energy Theorems and Structural Analysis. Aircraft Engineering, 26(11), 383-394.

• Felippa, C. A. (2001). A historical outline of matrix structural analysis: a play in three acts. Computers & Structures, 79(14), 1313-1324.

• National Academy of Engineering (2011). John H. Argyris 1913-2004. Memorial Tributes, Volume 15.

• Kurrer, K.-E. Biography of John Argyris, from The History of the Theory of Structures.

• Foschini Neto, N. (2020). John Hadji Argyris and the Computational Structural Analysis in British Aircraft Engineering.

• The Seattle Times (1995). Jonathan Turner, Airplane Engineer.

• ASME. Finite Element Analysis landmark brochure.

• Liu, W. K. et al. (2021). Eighty Years of the Finite Element Method: Birth, Evolution, and Future.

And yet, when I talk with simulation engineers, the conversation goes in a very different direction.

Over the past months, I have had many of these conversations with analysts, team leads and engineering managers. The same pattern keeps appearing: strong curiosity, limited visibility, and very few clear answers.

The questions nobody is answering clearly

Engineers ask practical questions. What is an agent, really? Is it just a script with a language model inside? How is it different from the macros and automated workflows we already use? And the one I hear most often: if an agent sets up the model and runs the solver, what is left for me?

Managers ask different questions, and they are just as unanswered. Where do we start? Do we have to replace the tool chain we spent years building? How do we validate what an agent produces, and who is accountable when it is wrong? What happens to our data and our IP?

The answers they find are often vague, or wrapped in marketing language. That is not good enough for a profession built on verification. We do not accept a result because the contour plot looks nice. We should not accept a technology because the demo looks impressive.

Why I organize this series

This gap is the reason I decided to organize Agentic AI in Simulation, a free two-part webinar series in collaboration with Synera.

The goal is simple: demystify agentic AI in FEA, in clear and practical terms, without the hype. Two sessions, each answering one question:

1. What is agentic AI in FEA?

2. And how do we make it work in a real engineering organization?

I want to be clear about my position from the start. Agentic AI is not a replacement for the analyst. Properly understood and properly governed, it lets engineers spend less time on repetitive execution and more time on the decisions that matter: assumptions, interpretation and design direction.

See details about the series

Part 1: Foundations and First Use Case

Tuesday, October 27, 2026 | 8:00 AM PDT | 11:00 AM EDT | 4:00 PM CET |

The first session builds the foundations:

1. What an agent is

2. Why it is not the same thing as a script, a macro or a workflow.

3. What it can do inside an FEA workflow, from geometry cleanup and meshing to solver runs and reporting.

4. Where the analyst stays in the loop.

Synera will then run a live demonstration: a realistic FEA task, handled end to end by an agent, in a workflow most analysts will recognize.

I will not give away the full framework here. But if you leave with one idea, it should be this one: automation follows instructions, while an agent pursues a goal and knows when to hand back control.

Part 2: The Practitioner’s Perspective

Thursday, November 12, 2026 | 8:00 AM PST | 11:00 AM EST | 5:00 PM CET |

The second session addresses the two questions that decide whether agentic AI ever leaves the pilot stage.

1. The first is the position of the engineer. What can the agent own, and what must stay with the engineer? When does the agent hand back control, and with what information? And the question every skeptical analyst asks, rightly: can I trust what the agent did? My short answer is that trust comes from the process, not from the tool. We will see what that means in practice.

2. The second is implementation. How do you bring agents into an organization without tearing out the CAD, CAE and PLM tools already in place? Which process should you start with? And what does it take beyond the technology, in validation practice, IT and data, and governance?

Our guest, Abhinav Tanksale, CAE Engineer at My Physics Cafe, used agentic AI in real simulation work. He will share what changed, what surprised him, what he was skeptical about, and where he still had to step in. Synera will also show a second, contrasting use case at a different stage of the workflow.

Who should join

The series is for simulation engineers who want to understand what agentic AI means for their daily work, and for engineering managers who need to decide whether, where and how to implement it. No prior experience with AI is required. A solid understanding of the FEA workflow is enough.

Both sessions are free, live on Zoom, with time reserved for your questions. You can register now, where you will find all the details:

Register for Free

The technology is moving fast. Engineering judgment is still what makes a result trustworthy. Let’s make sure we understand the first well enough to protect the second.

See you on October 27.

Dominique Madier
| FEA Academy Founder & Director |
| FEA Consultant | FEA Trainer and Coach | Book Author | Speaker |
| Helping Students and Engineers to Master FEA |

Four iterations versus one hundred

Ryan opened with a simple problem. A balloon-borne telescope needed a bracket to hold an optical assembly. NASA requirements, of course: stiff, strong, light. Done the traditional way, two engineers working two days produced four design and simulation iterations, and the part still fell short on performance and manufacturability.

With AI-driven design, one engineer in one hour ran more than 100 iterations and arrived at a part that was lighter, stiffer, stronger, and easier to make. On a sample return mission, a closure part had to be light enough to shut quickly and strong enough to take the impact of the sample. Human designs could not close that gap. The automated loop did.

Impressive numbers. But the most important part of Ryan’s talk came next.

The bottleneck moved

Once his team could produce structures this quickly, the slowest step was no longer design or analysis. It was getting the requirements from the project teams.

So they wrote a checklist. Without fully realizing it at first, they had standardized the inputs to their design process. They then documented how those inputs become the outputs: a manufacturable CAD model and a validation report. With that in hand, two interns turned the whole thing into code in about a week. As Ryan put it, once you have solved something with code, you have solved it forever. The same code now designs different mounts from different inputs, and the inputs can come from an AI agent rather than a person.

Ryan generalized this into what he calls a “Text to X” playbook:

1. Start from your design and simulation engines (CAD, FEA, topology optimization).

2. Standardize inputs and outputs.

3. Document the design process.

4. Automate the workflow.

5. Verify it on cases where you already know the answer.

6. Deploy it so agents can call it.

He then showed multi-agent systems designing a telescope’s optics and mounts, a bipod flexure, and a full CubeSat concept from a single paragraph of text.

Read that playbook again as an analyst. Nothing in it is about AI. It is about knowing your process well enough to write it down. The teams that benefit are the ones that already have discipline.

Airbus: from four to six weeks to one day

Patrick Kunert leads cost and value engineering at Airbus Aerostructures, and he started his career in design and stress. That background showed.

His team did not start with engineering. They started with the call-for-tender process in procurement, to learn the platform and connect their data. Then they moved to design-to-cost. Previously, taking an idea for a cheaper part to an approved change took four to six weeks, mostly communication and back-and-forth. His example was a titanium clip machined from a solid block. The automated workflow loops through costing, stress checks, and design changes, while fixed constraints, such as a minimum factor above one, cannot be touched.

The lead time dropped to one day. But Patrick insisted on a second benefit: the maturity of the decision. Instead of the engineer’s best guess at a better design, the team now chooses among hundreds of analyzed options.

When the remaining day turned out to be mostly meetings, they added a multi-agent system for change evaluation, with agents for data, stress analysis, costing, and tooling checks. The architecture matters: deterministic workflows sit underneath and handle what is known, and agents work on top where optimization is needed.

The analyst’s questions

The Q&A raised the questions I would have asked.

How do you know it works? Ryan’s answer was reassuring in its simplicity. NASA already has processes to catch human mistakes: simulation standards, testing at component, subassembly, and assembly level, and design reviews. The same processes catch agent mistakes.

What about determinism? Give the same problem to ten engineers and you get ten designs. Give it to the same engineer on Wednesday morning and Friday afternoon and you get two. Ryan accepts some non-determinism, as long as the result is validated.

What about fatigue? “If you can simulate it, you can automate it.” The requirement must simply be written in a form a computer can evaluate.

What about certification? Airbus currently automates only the steps upstream of regulated decisions, keeps a human at each critical checkpoint, and works step by step with its regulatory functions. Ryan added that many design rules, such as a minimum edge distance of 1.5 fastener diameters, can be written directly into the code, so compliance is built in rather than checked afterward.

Here is my own reading. “If you can simulate it, you can automate it” is true. The corollary is just as true: if your simulation is wrong, you will automate the error a hundred times an hour. The boundary conditions, the load cases, the material allowables, the failure criteria: these remain the analyst’s responsibility. Automation makes them more important, not less.

Coordination, not computation

Wallace Scott, who started his career as an FEA engineer, told a story many of you will recognize. He once worked on a topology optimization project with one expert for CAD, one for optimization, and one for FEA validation on another continent. The results were promising. The project died anyway, because it was impossible to get the right people in the room at the right time.

That is the real cost these tools attack. Not the solver time, but the handoffs.

At the end of the session, Wallace added a caution. If you optimize each step of a process in isolation, you can end up with a globally suboptimal result. Ryan replied that sometimes you find you do not need an agent at all, only a deterministic script, and AI helps you write it faster. It is the same discipline we apply in FEA: use the simplest model that answers the question.

What this means for you

Ryan’s advice to students applies to all of us: just start. Use the tools on work you already know well, so you can judge the output. Patrick said the same: know your process first, then see where AI changes it.

One remark from Wallace reframed the investment for me. Most engineering tools lose value over time. An agent built around a well-documented process gains value, because the models underneath keep improving. The knowledge you encode today is an appreciating asset.

And Ryan’s closing point on model choice deserves to be underlined. The models change every week. What makes an organization strong is its evaluations: the test cases with known answers that tell you whether a new tool, a new model, or a new workflow can be trusted. That is exactly the kind of verification work good analysts have always done.

Watch the recording

If you registered, the replay link is already in your inbox. If you did not register, you can still watch the full session here:

👉 Watch the recording: Time to First Article, NASA, Airbus & Agentic AI

Seeing the agents work step by step says more than any summary.

My thanks to Ryan, Patrick, Wallace, and Mike McClary of Aviation Week for an honest, practical session.

To perform high-quality finite element analyses, FEA analysts must acquire knowledge in many areas. FEA is a very powerful and versatile tool that, if used properly, will always generate accurate answers. However, without proper guidance, new users will easily make almost every possible mistake.

Learning FEA requires a combination of both technical and practical knowledge. To become an FEA specialist it requires a lot of practice, patience, and perseverance. The more problems you solve, the better and the more confident an FEA analyst you will become.

First, I must reiterate that understanding the modeling techniques is more important than knowing specific commands in an FEA software. If you are interested in the simulation of mechanical structures, you must learn FEA, rather than how to run a specific piece of software.

You should use FEA only when necessary, when simple hand calculation methods cannot be applied and for complex problems analytical methods cannot solve. Finally, never assume that the FEA results will be conservative; there are many situations in which an FEM will underestimate the results.

As an FEA analyst, you also need practical experience, a feel for design, and good engineering judgment to enable you to understand the product you are analyzing as well as its intended work environment. This knowledge is important when deciding which features must be accurately modeled, simplified, or omitted. It will also enable you to properly apply boundary conditions, analyze errors, and understand the results. In the end, you will be in a better position to discuss modifications with designers and serve the best interests of your engineering department.

When you have mastered FEA, you will be able to solve most mechanical problems but only if you follow good FEA modeling practices. Finally, note that the recommendations presented here are explained in detail in my book “Practical Finite Element Analysis for Mechanical Engineers – First Edition”. For each modeling practice mentioned in this article, I will give you the chapters numbers in reference in which you can find details in the book.

About the Book

GOOD MODELING PRACTICES APPROACH

The objective of an approach incorporating good modeling practices is to use FEA intelligibly and not as a black box, although, from a solving point of view, it is one. Your FEA will produce accurate results only if:

1. You understand the physics behind your problem.

2. You know what you are looking for.

3. You have an idea of what the results should look like.

4. You understand the behavior of the elements in the library of your FEA software.

5. You select the right elements for the task.

6. You perform the correct discretization (proper mesh density and good quality).

7. You apply the correct boundary conditions (constraints and loadings).

8. You understand the effects of your assumptions on the response of your model.

9. You know how to modify the model to improve its accuracy.

10. You keep a critical eye on the results, and you understand the critical outputs.

If you are a newcomer to FEA, start with a simple FEM. Do not attempt to set up a complex FEA from scratch. Make sure you understand the capabilities of your FEA software. It is hard to understand complex phenomena, or to find errors in a large and complex FEA if you do not have significant experience. Moreover, it is crucial to know beforehand what results to expect.

While FEA software vendors do their best to help users become FEA experts, you must ultimately understand how to properly use the tools, without treating FEA simply as an extension of CAD. Similarities between CAD and FEA are limited to geometry, at best. There is also a risk of assuming that the FEM’s accuracy depends solely on precise geometric representation. The problem with this assumption is that many other factors such as selection of the right elements, definition of the right boundary conditions, selection of an appropriate material model, the convergence study, and the results analysis, to name but a few, are ignored. FEA is complex, and geometric accuracy and attractive color plots alone do not guarantee high quality.

The most experienced FEA analysts are the most pessimistic, when it comes to the accuracy of their models. They have been let down in the past by erroneous models, rerunning their models several times and carefully examining all results before presenting any data to the client. History has shown that while computer simulation has been used to solve very complex problems, it has also been responsible for disasters, when some inputs are not considered, or when data is used incorrectly.

IT ALL STARTS WITH A GOOD PLAN

Even before launching your FEA software, sit down at your desk with a piece of paper and plan your analysis. Do not start the modeling work if you are unable to answer all the following questions:

1. What is the design objective?

2. Why is FEA the best tool for your problem?

3. What are the design criteria?

4. How much of the structure will need to be modeled?

5. What are the precise boundary conditions (restraints and loads)?

6. Which quantities do you need to predict: stresses, displacements, frequency, stability?

7. What error can you tolerate in your results?

See details in “Chapter 6 – Defining Your FEA Strategy” in “Practical Finite Element Analysis for Mechanical Engineers”.

UNDERSTAND THE PROBLEM IN DETAIL

1. If your intention is to precisely quantify the stress level in a critical region for your structure, during the simulation process, you must qualitatively understand in detail the problem you want to simulate.

2. Whatever simulation you submit to the FEA software, you will often obtain an answer, even if you specify an incorrect set of equations. Therefore, the first task of an FEA work project is to understand the physics behind the real structure and the real behavior of the parts you want to model. Then, you will be able to reproduce this behavior using a computer simulation. This approach allows you to completely understand what your FEA is doing.

BE SURE TO UNDERSTAND THE INPUTS AND REQUIREMENTS

Before beginning the analysis:

1. List the available inputs.

2. List the requested outputs.

3. Connect all the provided inputs with the analysis requirements.

4. Ask for additional inputs, if necessary.

DEFINE YOUR DESIGN OBJECTIVE

Answer the following questions before you begin modeling:

1. Is the problem to be solved so complex that you cannot answer it using a classical method?

2. How can FEA help you to answer the question?

3. Which question is to be answered?

4. Which quantities are to be calculated?

5. Do you want to capture a global or a local effect?

Here are a few rules to follow when defining the objectives of your simulation:

1. Identify your expectations for the finite element simulation.

2. Do not set up a simulation without a clear goal in mind.

3. Do not create a model, “just to see what will happen…”

4. Predict the behavior you expect to obtain.

5. Clearly identify the effects you need to simulate. For example, do not use a material plasticity model if you only need to know whether a yield stress is exceeded.

6. Identify the required precision of your calculation.

See details in Chapter 6 – Defining Your FEA Strategy in “Practical Finite Element Analysis for Mechanical Engineers”.

SELECT THE RIGHT TYPE OF ANALYSIS

Define the type of analysis required to capture the effects (linear, nonlinear, static, buckling, normal mode, frequency response, transient, etc.)

1. Is it a static or a dynamic problem?

   • If the loading is constant over a relatively long period of time, it is a static problem.

   • If the inertial and damping effects are negligible, it is a static problem.

   • If the loads are applied gradually, it is a static problem.

   • If the structure is subjected to vibrations, and the excitation frequency is less than one third of the structure’s lowest natural frequency, it is a static problem.

2. Is it a linear or a nonlinear problem?

   • If the stiffness of the structure does not change when a loading is applied, it is a linear problem.

   • If the strains in the model are less than 5%, it is a linear problem.

   • If the strains or stresses of the model do not exceed the proportional limit, it is a linear problem.

3. If it is a nonlinear problem, which type of nonlinearity is it?

   • Is it a large deformations problem (nonlinear geometric)?

   • Is it a material plasticity, hyper-elasticity… problem (nonlinear material)?

   • Do the boundary conditions change during the analysis?

   • Is it a contact problem?

   • Is it a combination of two or three of these?

4. If it is a contact problem, define the contact type:

   • Glued

   • Parts that are separate from one another

   • Is there friction, and do you want to model it? If yes, do you know the coefficient of friction?

Take the time to answer all these questions, which will allow you to define the type of analysis you should run and influence the assumptions you must make during the modeling process.

See details in “Chapter 20 – Linear Static Analysis”, “Chapter 21 – Nonlinear Static Analysis”, “Chapter 22 – Linear Buckling Analysis”, “Chapter 23 – Nonlinear Buckling Analysis”, “Chapter 24 – Normal Mode Analysis” in “Practical Finite Element Analysis for Mechanical Engineers”.

CHECK & CLEAN UP THE GEOMETRY

CAD models are usually very large. Reflect on what is essential to the analysis and for the model; it will likely not be the entire product. For example, a CAD model of a mechanical structure could include all the nuts and screws needed to assemble the parts. This may be unnecessary in the FEA, or they may be modeled using simple 1D spring elements. Many parts do not contribute to the effect you wish to capture, so take the necessary time to identify and remove them from the CAD.

Taking the time to perform an efficient geometry cleanup, prior to beginning the modeling process, is a good investment that will save you time later on. Check for duplicate geometric features (solids, lines, surfaces, etc.) and delete them. Remove the unwanted lines, fillets, holes, and beads before you start meshing the components.

After importing the CAD to your pre-processing software:

1. Check the dimensions of the imported geometry.

2. Scale the model before beginning the modeling process (if the CAD was created in a unit system that is different from the material data and loads you plan to use).

SELECT THE PROPER ELEMENTS

Choosing the element types is a crucial step in creating a good FEM.

1. Take your time reading the reference manual for the library of elements associated with the FEA software you are using.

2. Run simple test cases to make sure you know how to use them in the practical analysis.

3. Make sure you understand how a finite element simulation is affected by the choice of element type.

4. Make sure you understand the concepts of element order and integration points.

5. Use truss elements for axial and torsional strength (truss structure, actuator, tie-rod, stringer, flange cap, etc.).

6. Use beam elements for strength in bending, axial load (tension and/or compression), and transverse shear (frame structures, structures with large slenderness ratios).

7. Use 1D spring elements to replace complex parts with equivalent stiffness.

8. Use 2D shell elements for parts having a width:thickness ratio greater than 10 to 20 (skin, web, thin-walled structure, etc.)

9. Use quadrilateral elements, when possible, in a 2D shell mesh. Try to avoid the triangular elements, since they are much too stiff, especially in bending. Ensure the number of triangular elements in your model is negligible, compared to the number of quadrilateral elements. Ensure that triangular elements are not in the regions of interest.

10. Linear elements are usually preferred over quadratic elements in a 2D shell mesh.

11. Shells and membranes look similar but behave differently. Be sure to use the correct formulation.

12. Do not model thin-walled structures in bending with 3D solid elements. Only 2D shell elements can capture the bending stresses of a thin-walled structure.

13. Use 3D solid elements only to capture details that cannot be modeled with 1D or 2D elements.

14. The brick element (HEX8) is the preferred element (no locking under bending effects) in a 3D solid mesh.

15. The quadratic element (TET10) is preferred over the linear element (TET4), when solid TET elements are used.

16. At least two elements through the thickness are required in a 3D solid mesh with quadratic TET10.

17. It is not necessarily true that 3D elements outperform 2D elements or that 2D outperform 1D elements.

See details in “Chapter 7 – The Library of Elements” in “Practical Finite Element Analysis for Mechanical Engineers”.

CREATE AN INTELLIGIBLE MESH

Meshing is one of the key steps to produce a FEM which will be able to predict accurate results.

1. Run a preliminary simulation with a coarse mesh to confirm the critical regions.

2. Apply a fine mesh in regions with significant gradients in stress or strain.

3. Do not create a fine mesh for the entire model. Apply the finer mesh in regions of interest.

4. Create a coarse mesh for comparisons, stiffness problems, and load models.

5. Create a structured mesh in critical regions.

6. A finer mesh gives an answer closer to reality, so apply a converged mesh in regions where you want to extract stresses or strains.

7. If you do not know the mesh density needed for the converged mesh, perform a convergence study.

8. When using local mesh refinement, smooth the transition between the different regions. If the transition is too abrupt, spurious results may occur in this region. Adjacent elements should not differ by more than a factor of three in their area or volume.

9. Plot unaveraged stress and compare it to averaged stress to check the mesh.

10. Do not connect linear and quadratic elements.

11. Check your mesh quality using the checks available in your pre-processing software.

12. Build simple meshes, avoiding complexity.

13. Respect the physical interfaces.

14. Use glued contacts to join meshes and create assemblies of larger parts.

15. In 2D shell meshing, the ideal quadrilateral element is your goal: “If it looks good, it is good.”

16. Apply accurate properties to the elements to represent the geometry (shell thickness, beam cross section, inertia, etc.)

17. During the meshing process, discontinuities, called cracks, appear in the resulting mesh. To check for cracks in the model once the meshing process is completed, various methods are available:

    • Use a pre-processing software to plot the edges.

    • Run a dummy load case and have a look at the deformations.

    • Run a modal analysis and plot the mode shapes.

See details in “Chapter 8 – Meshing” in “Practical Finite Element Analysis for Mechanical Engineers”.

DEFINE THE RIGHT BOUNDARY CONDITIONS

During the process of creating an FEM, defining the boundary conditions is the stage at which many engineers make incorrect assumptions. The topic of boundary conditions is less understood by FEA beginners, but it is not uncommon for experienced engineers to also have difficulty properly defining them.

Boundary conditions have a major impact on the results of an analysis, and a small mistake when defining them can make the difference between a correct and incorrect simulation. To properly define your model’s boundary conditions, you will need to follow a strategy, which will permit you to test and validate them.

1. Predict how the model will behave using your engineering judgment, test results, or previous analyses.

2. Ensure that the set of boundary conditions (constraints and loadings) reflects real life.

3. Prevent rigid body motions.

4. Check the boundary conditions with a modal analysis.

5. Ensure that the deformation of supports is negligible.

6. Boundary conditions usually generate singularities, so keep them far from regions of interest.

7. Predict the load path before running your model.

8. Take advantage of the Saint-Venant’s principle.

9. Point loads may cause unrealistic stresses in adjacent elements (singularities). It is preferable to distribute a load over several nodes using a local mesh refinement, if needed.

10. If the direction of the boundary conditions varies during the simulation, run a nonlinear solution.

11. Check the boundary conditions after the run by observing deflections/reactions at the constrained nodes.

12. At a given node, set either the load or the displacement but not both.

13. Do not add stiffness to the model by creating excessive constraints such as redundant supports.

14. Ask yourself whether parts that were not included in the model could really allow the deflections you obtain with your simulation.

See details in “Chapter 11 – Defining Loads and Boundary Conditions” in “Practical Finite Element Analysis for Mechanical Engineers”.

VALIDATE THE INPUT DATA

1. A simulation cannot be more precise than its input.

2. If there are uncertainties associated with the material data or external loads, use a conservative estimate.

3. If there are uncertainties associated with the input data, vary the associated parameters to see how the results are affected by them.

MANAGE THE UNITS

Most FEA software are units-free:

1. Use units in such a way as to satisfy Newton’s Second Law of Motion.

2. Check mass and center of gravity with a modal analysis, or apply gravity and check reactions.

3. Verify that force, elastic moduli, acceleration, mass density, and dimensions represent consistent units.

See details in “Chapter 9 – Setting Your Units” in “Practical Finite Element Analysis for Mechanical Engineers”.

DEFINE CONTACT PROPERLY

Contacts define how parts interact and are typically used to understand behavior and load transfer within an assembly. Contacts are very useful in FEA simulations because they allow multiple bodies to interact, without the need to add elements to the model.

There are advantages to contact conditions in a model, since it is possible to model more realistic behaviors, but their addition to a simulation can be costly; contact conditions create significant computational complexity in a model, and numerous parameters must be managed by the FEA analyst. The consideration of contact often marks the transition point between linear and nonlinear simulations.

1. Use contact when absolutely necessary.

2. Use contact locally, not for all parts of a complex assembly.

3. The solution will take significantly longer to compute with the use of contact.

4. Try to use first order elements in the contact regions.

5. Ensure that you properly select the master and slave surfaces.

6. Be sure to remove rigid body motion of contact pairs before contact is established. This can be done by adding appropriate constraints or by using a stabilization procedure.

7. Does friction need to be modeled? If yes, what is the friction coefficient? You may need to run models with different values if the coefficient is not firmly established.

See details in “Chapter 14 – Modeling Contacts” in “Practical Finite Element Analysis for Mechanical Engineers”.

MODEL THE RIGHT MATERIAL BEHAVIOR

In terms of material properties, whatever the source is, it is an approximation.

1. Use an isotropic material (same properties in all directions) in a metallic part.

2. Use a 2D-orthotropic material (different properties in two directions) in a composite part modeled with shell elements.

3. Use a 3D-anisotropic material in a composite part modeled with solid elements.

4. Determine whether temperature dependence is important in the analysis. If not, model the material properties at room temperature or at the operating temperature.

5. Properly define the density, if inertial loads are involved in the analysis.

6. Properly define the coefficient of thermal expansion, if thermal stresses are required.

7. Model a boundary wherever material properties change.

8. For a nonlinear analysis, define whether the stresses are below the yielding point. If not, use a nonlinear material:

   • If the strains are recoverable, model a nonlinear elastic behavior.

   • If the strains are irrecoverable, model a plastic behavior.

   • Use the true stress-strain curve.

   • Ensure that the Young modulus matches the yield stress.

See details in “Chapter 10 – Material Modeling” in “Practical Finite Element Analysis for Mechanical Engineers”.

MANAGE THE SINGULARITIES

Real structures do not contain singularities. These are a fiction created by the simplifying assumptions of the model.

1. If your singularities are far away from the region of interest, you can ignore them.

2. If they are in the region of interest, you must take corrective action:

   • Model a pressure load instead of a point force.

   • Spread displacement constraints over a set of nodes, instead of at a single node.

   • Use material plasticity.

See details in “Chapter 11 – Defining Loads and Boundary Conditions” & “Chapter 17 - Understanding FEA Outputs” in “Practical Finite Element Analysis for Mechanical Engineers”.

SHOULD YOU MODEL THE ENTIRE STRUCTURE?

1. Define which portion of the structure you need to model:

   • Option 1: model the entire structure with a refined mesh. This requires more resources, compared to the other options.

   • Option 2: model only the region of interest with a refined mesh.

   • Option 3: model the region of interest with a refined mesh and the surrounding structure with a coarse mesh. This is an advantageous option because the boundary conditions for the region of interest, which are given by the surrounding structure, are very accurate.

2. Do you need to model the bolts? If yes, with which method?

See details in “Chapter 15 – Submodeling” in “Practical Finite Element Analysis for Mechanical Engineers”.

SHOULD YOU MODEL THE BOLTS?

Although the mechanical industry has developed technologies to manufacture integrally machined parts, additive material processes, friction stir welding, and so on, many small and large structures still require the use of old-fashioned bolted joints.

1. Bolts are not usually modeled with a 3D approach, because we are not interested in stress in the bolts but only in the load transferred by the bolt, so a beam or discrete spring element is sufficient.

2. Do not model bolts with 3D elements: use MPC + beam, MPC + 1D discrete spring, or Rutman fasteners.

3. The behavior of a joint may be influenced by the bolt preload. This preload can be included in the model even if the bolt is modeled with a 1D element.

See details in “Chapter 13 – Modeling Bolted Joints” in “Practical Finite Element Analysis for Mechanical Engineers”.

VERIFY AND VALIDATE YOUR MODEL

In FEA, both careless users and experienced engineers who are not careful to systematically validate their models can easily make significant mistakes. Expensive decisions in terms of both time and money can sometimes turn out be based on incorrect answers. FEA is demanding, in the sense that the FEA analyst must be proficient not only in mechanics but also in mathematics, computer science, and especially FEA itself. Therefore, it is important to employ validation and correlation procedures whenever FEA is used to solve a problem.

1. Verify your model to ensure that you have applied the correct boundary conditions (loads and constraints).

2. Do not assume the model is correct. Perform standard checks before running your model for results:

   • Accuracy checks

   • Mathematical checks

3. Check the shapes and sizes of the elements. Use the tools provided by your pre-processing software to highlight critical elements. Avoid badly shaped elements, especially in regions of interest and where high gradients occur.

4. Validate the model by making a prediction that was not used in specifying or calibrating the model. For example, apply a very simple loading for which you can perform a hand calculation and verify that the results are the same.

5. For a given surface, orient all the elements normal in the same direction, to apply consistent pressure.

6. Perform all checks prior to releasing your FEA.

7. If possible, correlate your model with test data.

8. When conducting correlation with test data, ensure you apply the same boundary conditions as in the test. It is possible that test conditions will differ from the structure’s real-life environment.

9. Each time you significantly modify your model, you should check it again.

See details in “Chapter 16 – Validating and Correlating Your FEA” in “Practical Finite Element Analysis for Mechanical Engineers”.

MANAGE INCOMPATIBLE DEGREES OF FREEDOM

Three methods are available to connect two elements having incompatible degrees of freedom:

1. Use R-type elements to connect beam to shell elements.

2. Use R-type elements to connect shell to solid elements.

3. Use extra elements.

See details in “Chapter 7 – The Library of Elements” & “Chapter 12 – Rigid Body Elements and Multi-Point Constraints” in “Practical Finite Element Analysis for Mechanical Engineers”.

KEEP AN EYE ON THE SOLUTION’S PARAMETERS

1. In all FEA software, each solution contains many parameters that are not specified by the user. Make sure you know and understand all these parameters.

2. Make sure you understand how these parameters will affect the solution.

3. If you do not know a parameter, refer to the manual of your FEA software before submitting your run.

KEEP A CRITICAL EYE ON THE RESULTS

Today, finite element simulations are used to simulate very complex structures and mechanical systems. Thanks to the immense calculation capacity of modern computers, it is possible to solve extremely refined FEMs. A consequence is the vast amount of output data for these simulations, which is where post-processing comes into play.

Postprocessing is often defined as the “art of results interpretation.” The quantity of results generated by the solver is so large that the FEA analyst needs to use a dedicated software, called a post-processing software, to organize and interpret the results.

1. Never believe simulation results without considering their plausibility.

2. Always trust your engineering judgment.

3. Never accept simulation results that are not in line with your engineering judgment.

4. Always look at the deformed shape first, even if you are more interested in stresses and forces.

5. Ask yourself whether the deformation shapes make sense and are in line with your predictions.

6. Post-process the appropriate stresses. For example, the von Mises stress is irrelevant for a brittle material.

7. Check whether the constrained nodes behave as expected.

8. Pay special attention to regions where gradients are large. If high gradients occur in a region of interest, apply a finer mesh.

9. Ensure that discontinuities in the stress field are not the result of a change in the numerical stiffness (too abrupt a change in element size, for example).

10. In the contact regions, check that the mesh properly represents the deformation of the surfaces in contact. If not, refine the mesh in the contact region.

11. When running a linear solution, verify that the displacements are small and that the stresses are not greater than the yield.

12. Ask yourself whether high stress near the boundary conditions is fictitious or real.

13. Check if the displacements are in the expected range.

14. Do not focus too much on the hot spots; check the global behavior.

15. Check reactions against applied loads: what goes in must equal what goes out.

16. Perform a free body diagram check, based on reaction forces.

17. Plot non-averaged stresses.

18. Perform animations of the deformed shapes.

19. If you combine loadings, consider separating them to better understand the effect induced by each load type.

20. Perform a sensitivity study to evaluate the effects of input parameters on response.

21. Compare results to previous analyses or test results, when possible.

22. Do not assume the model is correct simply because the solver generates an answer.

23. Do not use an FEA for a purpose other than the one for which it was developed. For example, do not perform a buckling analysis with an FEA created to capture the load transfer in a joint. Every FEA is developed to answer a specific set of questions. All the assumptions have been made to answer these questions. If the FEA is used to predict an effect that was not considered during its development, your prediction will be incorrect.

See details in “Chapter 17 – Understanding FEA Outputs” in “Practical Finite Element Analysis for Mechanical Engineers”.

DOCUMENT EVERYTHING

1. Keep an updated journal throughout the development process containing the CAD references (drawing numbers with revisions), names of FEA analysts and/or suppliers involved in the building of the model, and different model versions with a history of updates.

2. Document all FEA assumptions:

   • The FEA’s objectives

   • Element types

   • Material data

   • Coordinate systems

   • Meshing assumptions

   • Convergence studies, if required

   • Boundary conditions

   • List of load cases

   • Contact types

   • MPC types and R-type elements used, with their purposes

   • Description of joints (methods used to compute stiffness)

   • Solution type, with associated parameters

3. Document the accuracy checks and mathematical checks.

4. Document the correlation and calibration.

See details in “Chapter 19 – Documenting Your FEA” in “Practical Finite Element Analysis for Mechanical Engineers”.

ASK FOR HELP

While you are developing an FEA, you will face problems you will be unable to solve, and you should not hesitate to ask for help. There are many different ways to get help.

1. Ask colleagues around you or among your contacts. The solution to a problem you are facing will often have been found by another FEA analyst.

2. Contact your FEA software support.

When you need to contact technical support or a technical forum, some best practices are recommended:

1. Do your homework before asking a question.

   • Read the manual.

   • Create a simple test model to illustrate your question. A specialist may be willing to correct a simple problem but will not want to look at your model with a million elements.

2. Be specific about the question and only supply the required information to the specialist.

   • Focus your question on a single solution. If you have multiple questions that are unrelated, you must create an independent request for each one.

   • Provide as many details as the specialist needs to answer your questions, but don’t provide unnecessary information. For example, a specialist will not need to know a part’s dimensions, or the specific type of steel.

3. Don’t post your question more than once.

   • Nothing irritates a specialist more than discovering that a customer has submitted a question twice without waiting for the original answer. It is perfectly fine to ask the specialist for clarification once you get a response, but don’t ask repeatedly without acknowledging the initial request. You will be found out, and your future calls will not get the same attention.

4. Don’t assume you have found a software bug.

   • Issues are due to user errors, not bugs, 99% of the time. If you do find a bug, the best chance of getting it fixed is to replicate it with a simple test case that you can send to technical support.

   • Once they find one bug, FEA analysts tend to assume all errors going forward are also bugs. Don’t fall into this trap! Make sure that future errors are not the result of your own bad input before reporting them.

THE MOST COMMON MISTAKES IN FEA THAT YOU WILL MAKE AT LEAST ONCE

1. Conducting an analysis with little to no understanding of the physics behind the analyzed phenomenon

2. Not understanding how the structure is likely to behave

3. Not knowing enough about the library of elements in the FEA software used for the model

4. Not being sufficiently aware of the end requirements

5. Not checking and validating the FEM

6. Using 3D elements, instead of 2D elements

7. Using triangular elements, instead of quadrilateral elements

8. Null Young modulus or Poisson’s factor in a material definition

9. Insufficient supports

10. Part of the model is a mechanism

11. A large stiffness difference among parts

12. In a nonlinear analysis, a support or a connection reaches zero stiffness

13. Incorrect element data (incorrect thickness, beam cross section dimension, beam orientation)

14. Incorrect supports, in terms of location, type, or direction

15. Incorrect loads, in terms of location, type, direction, or magnitude

16. Using a non-consistent unit system

17. Duplicate elements

18. Incompatible elements connected together

19. Unrealistic boundary conditions

20. When post-processing stress, not checking unaveraged stresses

21. Post-processing components in an incorrect coordinate system

22. Post-processing in a singular region

23. Post-processing stresses in a region that has not been meshed with a converged mesh

24. Relying only on graphics without double-checking input data

25. Underestimating the resources and timescale required for the analysis

26. Not listing the assumptions made for the analysis

27. Including too much detail

28. Running the incorrect solution, for example, running a linear solution when the modeled component operates in a large displacement range and the material behaves in the plastic range

THE 10 COMMANDMENTS OF THE FEA ANALYST

Follow the good practices and apply the validated modeling techniques.

The Plot Nobody Could Defend

A few years ago, I sat in a design review where a young engineer presented a beautifully rendered stress plot of a machined part. The mesh was fine, the colors were clean, and the report was polished. The peak von Mises stress sat comfortably below the allowable, and the margin of safety was positive.

I asked one question: “Before you ran the model, what stress did you expect?”

Silence. Not because the engineer was lazy or incompetent. Quite the opposite: bright, motivated, and fluent in the software. They had simply never been asked to predict anything. The model was the prediction.

When I sketched the load path on the whiteboard and ran a quick beam calculation, the hand estimate came out roughly three times higher than the FEA result. The boundary conditions were wrong. The part had been fully fixed at a location where, in reality, it could rotate. That part had already passed two internal checks before it reached me.

So here is the position I want to put in front of you, knowing that many of you will disagree, some of you strongly:

No engineer should be allowed to run a finite element model until they can estimate the answer by hand within a reasonable margin.

Not “understand the theory.” Not “have taken a course.” Predict the answer. Write down a number before pressing Solve, and be able to explain why the software agrees or disagrees with it.

I am not saying this to protect senior engineers’ territory, and I am not nostalgic for slide rules. I have spent more than 25 years in aerospace structural analysis, and the last several years training more than 1,000 engineers from 50 countries. The pattern I see is consistent, and it worries me more every year.

Software First, Physics Later

Most engineering graduates today meet finite element software before they have developed any real intuition for how structures carry load. The reasons are understandable. Universities are under pressure to teach the tools that appear in job postings. Students can learn meshing, element menus, and contour plots in a single semester, while learning to see a load path takes years.

Hiring reinforces the same pattern. Job ads list software names. I have never seen one that asks for “can estimate the bending stress in a cantilever in five minutes.” So a new engineer’s value is measured by software fluency, and that is what they optimize for.

The outcome is a dangerous combination: high confidence and low verification ability.

Here is the uncomfortable truth about FEA. The software never refuses to give you an answer. Apply the wrong constraints, mix your units, forget a load case, and it will still return a converged, color-coded result. A wrong plot looks exactly as authoritative as a right one. FEA output carries no built-in credibility signal.

The only credibility check that exists is the analyst’s independent expectation. Without one, the analyst is not analyzing. They are transcribing.

Think about the errors that reach reviews in your own organization:

• Supports that are over-constrained and stiffen the structure artificially

• Point loads applied to a single node, with the resulting singularity reported as the peak stress

• Shell thicknesses or material properties entered in the wrong units

• Reaction forces that were never summed and compared to the applied loads

Every one of these would be caught by a ten-minute hand estimate made before the model was solved. Not after, when the plot has already shaped everyone’s expectations.

Prediction Is the Analysis

We need to change how we think about what FEA is for. It is not a machine for discovering answers. It is a tool for refining and verifying a hypothesis you already hold.

Every engineer learned the scientific method: hypothesis first, experiment second. A model solved without a prediction is an experiment without a hypothesis. You cannot be surprised by the result, which means you cannot learn anything from it.

When your hand calculation and your FEA agree within a reasonable margin, you gain confidence in both. When they disagree, that disagreement is the single most valuable piece of information in the entire analysis. Either your mental model of the structure is wrong, and you learn physics, or your finite element model is wrong, and you find the error. Both outcomes make you a better engineer. Without a prediction, neither happens.

Let me be precise about “reasonable margin,” because this is where critics will push back first. I am not asking anyone to hand-calculate a stress concentration at a fillet or the load distribution in a complex bolted joint. That is exactly what FEA is for. I am asking for the global behavior:

• The reaction forces and where they go

• The order of magnitude and location of the maximum displacement

• The nominal stress in the primary load-carrying members

• The way load flows from where it is applied to where it is reacted

If you cannot estimate the nominal stress, you have no way to judge whether the peak stress in your plot is plausible. And if you cannot judge that, you should not be the one signing the report.

Experienced analysts do this almost unconsciously. It is what we usually call “engineering judgment,” and it is often described as something mysterious that only comes with gray hair. It is not mysterious. Engineering judgment is simply a large collection of predictions that were checked against results. Which means it can be trained, deliberately, from day one.

“Isn’t This Just Gatekeeping?”

I know the objections, because I have heard every one of them in workshops and coaching sessions. Let me take them head on.

“This is gatekeeping.” Yes, it is a gate. Every profession where mistakes carry real consequences has gates. The question is what the gate is based on. A gate based on seniority, title, or years served is unfair. A gate based on demonstrated competence, one that a motivated engineer can pass in a few months, is the opposite. It gives juniors a clear, objective path instead of waiting for someone senior to decide they are “ready.”

“Universities don’t have time for this.” Universities don’t have time not to do this. Button sequences can be learned from a video in an afternoon, and every software vendor offers tutorials. What only a university can build is physical intuition. Every lecture hour spent navigating menus instead of drawing free body diagrams and tracing load paths is a misallocation of the most valuable teaching time an engineer will ever get.

“We need people who are productive on day one.” Productive at what? Producing results that someone else must recheck? Or, worse, results that nobody rechecks? The cost of one undetected error in a flight-critical part, a pressure vessel, or a lifting structure dwarfs the cost of a few months of structured onboarding. Speed without verification is not productivity. It is deferred risk.

“AI will soon set up the models for us.” This is the strongest argument for my position, not against it. As model setup becomes automated, the only human contribution left is judging whether the result makes sense. An engineer who cannot predict the answer cannot supervise an AI either. They simply add a second layer of unverified confidence on top of the first.

“How am I supposed to learn if I can’t touch the software?” Touch it all you want. Build models, break them, experiment. The restriction applies to results that feed decisions: design reviews, stress reports, and sign-offs. Learning is unrestricted. Accountability is earned.

Earn Your License: A Progression You Can Use Tomorrow

Criticism is easy. Here is what I recommend instead, and what I have seen work in teams of every size. Think of it as a license that engineers earn by demonstrating competence, not by accumulating years.

1. Level 0: Predict on paper. Work through a set of classic cases: a cantilever beam, a plate with a hole, a thin-walled pressure vessel, a simple frame, a single-shear bolted joint. For each one, estimate reactions, maximum displacement, and nominal stress by hand. The target is agreement within about 20 percent of a reference solution.

2. Level 1: Shadow models. Build finite element models of those same cases and compare them to your own predictions. For every discrepancy, write one paragraph explaining its source. None of this work leaves the team. Its only purpose is calibration.

3. Level 2: Prediction first on real work. For every production model, submit a one-page prediction sheet before solving: the expected load path, reaction forces, location and magnitude of maximum displacement, and nominal stress in the critical members. The reviewer checks the prediction sheet as carefully as the results.

4. Level 3: Independent analyst. After a consistent track record, meaning several consecutive models where predictions and results were reconciled and every discrepancy was correctly explained, the engineer signs off their own work under normal peer review.

5. Level 4: Reviewer. Only now does the engineer review the work of others. And most of that review boils down to one question: “What did you expect, and why?”

Two points matter here. First, the progression is based on competence, not calendar time. Some engineers reach Level 3 in six months. Others need two years. Both are fine. Second, it costs almost nothing to implement. The core tool is a single-page prediction template. The return is a team that catches its own errors before they reach a review, a customer, or a certification authority.

The Software Is Not the Problem

Let me be clear about one thing. I love these tools. Finite element analysis has transformed what engineers can design, and I have built a career on it. The problem is not the software. The problem is the sequence.

Software amplifies whatever judgment you bring to it. Bring strong physical intuition, and it makes you extraordinarily capable. Bring none, and it amplifies nothing, very convincingly, in beautiful colors.

This is the principle behind everything we teach at FEA Academy: fundamentals first, software second, judgment always. If you are curious where you stand today, the FEA Competence Diagnostic on fea-academy.com asks exactly the kinds of questions I described above. It takes a few minutes, and many engineers tell me the result surprised them.

Now I want to hear from you, especially if you disagree:

• Junior engineers: Is this fair, or does it feel like the profession pulling up the ladder behind itself? Tell me where I am wrong.

• Managers and team leads: Would you implement a prediction-first rule on your team? What would stop you?

• Educators: What would you remove from your curriculum to make room for this?

• Senior analysts: Be honest. When was the last time you wrote down a prediction before pressing Solve?

Leave a comment below. I read every one, and the strongest arguments on both sides will shape a follow-up piece.

Most analysts learn to debug FEA models the same way they learn to ride a bike: by falling off repeatedly until something clicks. A model fails to converge, and we start pulling levers. We tighten a tolerance. We soften a contact. We mesh a little finer in the area that looks angry. Sometimes it works. We move on, relieved, without ever knowing which change actually fixed the problem, or whether we just got lucky.

That is troubleshooting. It is reactive, it is trial and error, and it depends heavily on intuition built from years of scar tissue. It is also, frankly, how most of us were trained, because almost nobody teaches debugging as a discipline in its own right. We are taught how to build a mesh, how to define a material, how to apply a boundary condition. We are rarely taught how to systematically prove that the model we built is actually solving the problem we intended to solve.

That gap is the reason we built an entire course around it. Debugging deserves the same rigor as meshing or material selection. It is not a skill you either have or do not have. It is a process, and like any process, it can be taught, structured, and repeated.

See the course "Model Debugging in FEA"

Verification and Validation: Two Different Questions

Before any debugging conversation goes further, it has to start with a distinction that gets blurred constantly in practice: verification versus validation.

Verification asks whether we are solving the equations correctly. Validation asks whether we are solving the correct equations. These sound similar, but they are answering entirely different questions, and conflating them is one of the most common sources of false confidence in simulation work.

A model can be perfectly verified, mathematically consistent, well converged, numerically sound, and still be validating the wrong physics entirely. Maybe the boundary conditions do not represent the real constraint. Maybe the load path assumed in the idealization does not match how the structure actually behaves. A beautifully converged solution to the wrong problem is still the wrong answer.

Conversely, a model can represent the physics reasonably well but contain numerical errors that corrupt the result before validation even becomes relevant. This is why debugging has to happen in two layers, and why treating “it converged” as synonymous with “it is correct” is one of the more expensive habits an analyst can carry into a career.

Debugging as Preventive Engineering, Not Damage Control

There is a mindset shift that separates analysts who dread debugging from those who treat it as routine. The former see debugging as something that happens to them when a model misbehaves. The latter build verification into the process from the start, so that by the time a model runs, most of the common failure modes have already been eliminated.

This is the core argument behind treating debugging as preventive engineering. If you wait until a nonlinear run has been chugging for six hours before checking whether your units are consistent, you have already lost the six hours. If you wait until a stress result looks suspicious before checking whether your model is in equilibrium, you have already spent time interpreting a number that was never trustworthy to begin with.

The fix is not more experience or better instincts. It is a checklist, applied before the solver is ever launched, that catches the errors experienced analysts have learned to fear precisely because they have been burned by them before.

The Fastest Discriminating Test Wins

Once a model does misbehave, whether it fails to converge or produces a result that does not pass the smell test, the instinct for many analysts is to start changing things. A better instinct is to start eliminating hypotheses.

Not every check is equally valuable. Some tests are cheap to run and rule out large categories of error in seconds. Others are expensive and only confirm what you already suspected. The principle worth internalizing is simple: run the cheapest test that eliminates the most possibilities first. A quick free-free modal check, for instance, can immediately reveal whether a model has unintended rigid body motion, unconnected parts, or a mechanism, long before you need to look at contact status or material nonlinearity.

Common FEA errors tend to cluster into recognizable families: geometry and meshing issues, boundary condition issues, contact and nonlinearity issues, and solution or IT issues. Each family has its own symptoms and its own fast detection checks. Learning to recognize which family a given failure belongs to, rather than guessing at individual causes, is what turns debugging from an art into triage.

The Model Verification Toolkit

The centerpiece of a structured debugging process is what we call the model verification toolkit, and it splits neatly into two categories.

The first category is accuracy checks: eighteen items you inspect directly in the preprocessor before a solver is ever invoked. These cover the basics that are easy to overlook precisely because they seem too obvious to check: units, dimensions, material properties, mesh quality, part connectivity, shell normal directions, coordinate systems, and mass properties, among others. None of these checks require a solve. All of them prevent the kind of error that turns a five minute analysis into a five hour investigation.

The second category is mathematical validity checks, and there are three that matter most:

The free-free modal check, which removes all constraints from the model and runs a normal modes analysis. If the first six modes (or however many rigid body modes your model should have) are not near-zero frequency, something is disconnected, over-constrained, or mislabeled.

The unit gravity or enforced displacement check, which applies a simple, predictable load case and confirms the model responds the way basic mechanics says it should.

The free thermal strain check, which applies a uniform temperature change with no constraints and confirms the model expands or contracts freely, without spurious internal stress.

These three checks are inexpensive, fast, and remarkably effective at catching errors that would otherwise surface much later, and much more expensively, in a full nonlinear run.

Supporting all of this is a smaller set of concepts every analyst should be fluent in: reading the singularity and grid point singularity table, understanding the epsilon vector as a residual error measure, and confirming equilibrium through weight, applied load, and reaction force checks. None of these are exotic. They are fundamentals, and fundamentals are exactly what gets skipped when deadlines tighten.

When Convergence Fails: Reading What the Solver Is Actually Telling You

Nonlinear convergence failure is where most analysts feel the most lost, because the solver’s error messages can seem cryptic and the failure can feel arbitrary. It is not arbitrary. An implicit solver using a Newton-Raphson process is doing something very specific: it is iterating toward equilibrium by linearizing a nonlinear problem repeatedly and checking whether the residual has shrunk enough to declare victory.

When that process fails, the cause almost always traces back to one of four drivers: mesh quality, solver settings, material behavior, or contact conditions. Learning to distinguish between these, rather than randomly adjusting time step size or tolerances, is the difference between a five minute diagnosis and an afternoon of blind guessing.

Contact problems deserve special mention because they are consistently among the most common sources of convergence failure and the most misunderstood. A structured contact diagnostic toolbox, built around six specific checks, initial status, status history, pressure distribution, penetration depth, force vectors, and energy ratio, turns “the contact is not working” into a specific, answerable question with a clear pass or fail criterion for each check.

When It Converges but Looks Wrong

The other half of debugging is the quieter, more insidious problem: a model that converges cleanly but produces a result that does not make physical sense. This category of error is more dangerous than an outright convergence failure precisely because nothing stops you from trusting it.

The fix here is the same discipline applied to a different stage of the process. Displacement results and stress results both need consistency checks against expected physical behavior. Stress singularities, which are a mathematical artifact of certain geometric features rather than a real structural concern, need to be recognized and correctly interpreted rather than mistaken for genuine failure. Unexpected deformation patterns, possible rigid body motion, and reaction force imbalances all point toward specific, traceable causes when inspected systematically rather than dismissed or over trusted.

Advanced Territory: Snap-Through, Instabilities, and Solver Logs

For analysts working on the harder end of nonlinear analysis, debugging expands further into territory that includes reading solver logs and error messages as diagnostic data rather than noise, deciding when to switch from force control to displacement or arc-length control, and using strain energy and hourglass energy checks to catch mesh problems that would otherwise hide inside a converged but physically meaningless solution.

Building the Habit

None of this works as a one-time read. The value comes from repetition, from running the same accuracy checks on every model until they become automatic, from applying the same triage logic every time a solver throws an error instead of reaching for whatever fix worked last time.

That is really the underlying goal of teaching model debugging as a formal subject: not to hand analysts a list of tricks, but to install a habit of systematic thinking that holds up regardless of which software, which industry, or which type of nonlinearity you are dealing with. The tools change. The process does not have to.

If your team is still debugging by instinct and hoping the next fix sticks, it might be worth asking what a structured verification process would save you, not just in hours, but in the confidence you can put behind every result that leaves your desk.

See the course "Model Debugging in FEA"

The complaint was reasonable on its face. Stress sign-off was the last gate before release, and stress sign-off was late. So the program did the obvious thing and bought more compute.

It changed nothing. The solve had never been the problem.

I have thought about that program many times since, because it illustrates something that took me years to say clearly: in aerospace structures, the metric that governs is time to first article, and almost none of that time is spent solving equations.

What the clock is actually measuring

“First article” is the first production part built to the released design, the one that gets inspected against the drawing and either passes or sends everyone back to work. Time to first article is the interval from a design intent existing to a physical, conforming, defensible part existing.

Between those two points sits a structural analysis cycle that looks, in practice, roughly like this.

You wait for a loads deck. You get one, and it is preliminary. You wait for geometry. You get one, and it is not the configuration the loads were built for. You reconcile the two, or more often you build the model anyway with a note about it. You clean geometry that was created by someone with no idea it would be meshed. You idealize. You mesh. You apply a load case matrix, and somewhere in that matrix is a case that nobody can tell you the origin of. You solve, and this part takes twenty minutes. You post-process. You find something. You go back three steps. You solve again. You write the report. The report goes to review. Review produces a finding, sometimes about the physics and often about the traceability. You go back four steps.

Then the configuration changes, and a meaningful fraction of that work is done again.

If you have ever tried to account honestly for where an analyst’s month went, you know the shape of the answer. A small slice is modeling judgment, the part that requires an experienced engineer and could not be done by anyone else. A slightly larger slice is real interpretation of results. Everything else is preparation, reconciliation, repetition, and documentation.

The last category is the one nobody puts on a chart, and it is the one that sets time to first article.

Why this is the interesting problem for AI

I have been skeptical, in public and at some length, about AI in simulation. My skepticism has never been about capability. It has been about placement.

Most of what gets pitched aims at the wrong slice. Surrogate models that replace the solve are attacking the twenty minutes. Tools that suggest modeling approaches are attacking the part that should stay with the engineer, because that is the part nobody can verify after the fact.

The connective tissue is different. Fetching the current configuration. Reconciling a loads deck against a geometry revision and flagging the mismatch instead of quietly proceeding. Applying a documented cleanup and meshing recipe. Running a load case matrix from a controlled source. Extracting the same twelve quantities you always extract. Assembling the report in the template your organization has used since 2014.

That work is repeatable, deterministic, and checkable. It consumes a large share of the calendar. And it is where an agentic system can take real time off the clock without asking you to trust it about anything that matters.

The aerospace-specific catch

There is a reason aerospace has been slower than other industries here, and it is not conservatism for its own sake.

Our output is not a number. It is evidence. A stress report is an artifact that has to survive a certification review, potentially years after the person who wrote it has moved on. Every value has to trace back to an input, an input version, a method, and a decision, and the trace has to be legible to someone who was not in the room.

This makes automation harder, not easier. A tool that produces the right answer with no defensible provenance has produced nothing usable. Automation in this domain has to generate the trail as a first-class output, not as an afterthought, and that requirement rules out a great deal of what is currently being marketed.

It also means that when organizations like NASA and Airbus have actually put this into production work, the interesting part is not that it worked. It is what they had to do to make it defensible.

Which is why I am recommending this session

On September 29, Synera and Aviation Week are running a joint session titled Time to First Article: NASA, Airbus and Agentic AI, with speakers from both organizations walking through their aerospace engineering use cases.

The format is what makes it worth your ninety minutes. It is not a panel about the future of AI. It is engineers from two of the most process-constrained organizations in the industry describing projects they actually completed, with technical detail attached.

I have written a lot in this newsletter about the gap between what simulation tools promise and what they deliver on a real program. This is a chance to close some of that gap with evidence rather than opinion, from people whose evidence standard is higher than most.

Register Here for Free

Speakers:
Patrick Kunert - Head of Cost & Value Engineering, Airbus Aerostructures.
Mike McClary – Moderator - Writer and Editor, Aviation Week.
Ryan McClelland - AI Infusion Lead, NASA Goddard Space Flight Center.
Wallace Scott - Head of US Business Development, Synera

As always, register even if the time does not work. Registration gets you the recording.

The question I will be asking

If I get to ask one, it is this.

Not “how much faster was it,” because that number is easy to produce and hard to trust. The question is: what did you have to change about your process to make the output defensible in a certification context?

That answer is the one that tells you whether this is a tool or a toy. I will report back on what I hear.

Register Here for free

Disclosure: I write about the sessions I think are worth your time, and my assessment of them stays my own.

The Confidence Gap

Many engineers tell me the same story after their first encounters with Finite Element Analysis. They spend hours setting up a model, carefully applying loads, constraints, and material properties, and when the solver finally runs, they stare at the colorful contour plots with mixed emotions. On one hand, there is excitement at seeing the results. On the other hand, there is doubt. Can these results be trusted? Do they reflect reality, or are they just numbers produced by a machine?

This doubt is natural. FEA is a powerful but complex tool, and without a structured approach, it can produce results that are misleading. Confidence in FEA is not built by trusting software blindly. It is built step by step, by applying engineering fundamentals, by verifying assumptions, by validating against reality, and by cultivating habits that separate reliable simulations from false comfort. In this article, I want to show you how engineers can build that confidence, and why it is essential for professional growth.

Starting with Fundamentals

The first foundation of confidence is engineering fundamentals. No matter how advanced the software is, nothing replaces a quick calculation done on paper or in a spreadsheet. Simple beam theory, plate equations, or basic stress analysis provide order-of-magnitude checks. When your FEA model predicts a deflection of 10 mm and your hand calculation suggests 1 mm, alarm bells should ring.

I often tell my mentees that FEA should not be the first calculation you make, but the last. The role of FEA is to refine, to capture complexities, to explore variations. But its credibility comes from agreement with simpler models. If you cannot check your work against first principles, you cannot be confident in your results.

Verifying the Model Setup

Confidence also depends on knowing that your model reflects reality. This means paying attention to boundary conditions, materials, and connections. Too many engineers stabilize a model with artificial constraints just to make it run. They forget that every constraint changes the load path and the stresses. Similarly, small mistakes in material properties, wrong units, missing nonlinear behavior, incorrect temperature dependence, can invalidate the entire analysis.

Contacts and connections are another common source of error. A bolt modeled as fully fixed gives a very different response than a bolt modeled with compliance or contact. A gap modeled as glued contact may show no separation when, in reality, detachment is inevitable. Each of these details can swing results dramatically, and confidence only grows when you know your model matches the physical setup as closely as necessary.

The Importance of Mesh Convergence

FEA is built on discretization, and the mesh is at the heart of it. An inexperienced engineer may create a fine mesh everywhere, believing that more elements automatically mean better accuracy. But this is neither efficient nor sufficient. The real test of accuracy is mesh convergence. By refining the mesh in areas of interest and observing whether stresses or displacements stabilize, you know whether your solution is reliable.

Confidence comes not from a single result, but from seeing results stabilize as the model improves. A contour plot from a single mesh can be misleading. A trend across mesh refinements gives you certainty. I encourage every engineer to build the habit of mesh verification, even on simple models. It is the best insurance against false confidence.

Interpreting Results with Caution

Even with the right setup and a converged mesh, results must be interpreted carefully. FEA is notorious for producing stress singularities, those infinite spikes at sharp corners or point loads. Beginners often panic when they see stresses higher than material limits at such locations, but experienced engineers know these are numerical artifacts. The important question is whether the stress field away from singularities is realistic.

Similarly, averaged or nodal stresses may tell a more reliable story than peak elemental values. Hot spots must be distinguished from genuine weak points. Confidence in results grows as you learn to separate artifacts from reality. It is not about trusting the first number you see, but about reading results like an experienced interpreter of a language, knowing which words carry meaning and which are noise.

Validation Against Reality

Ultimately, confidence comes from validation. Whenever possible, compare your simulations to experimental results. Even if you cannot test the exact structure, benchmark your methods against standard problems or published studies. If your simulation of a simple beam or plate matches known solutions, you gain confidence in your approach.

Validation is also about correlation. You may not match every test point perfectly, but you should capture the right trends. If your simulation consistently underpredicts stiffness or overpredicts strength, you can calibrate. If it shows completely inconsistent behavior, you know something fundamental is wrong. Confidence grows when you see that your model aligns with reality in a systematic way.

Sensitivity and “What-if” Studies

Another powerful way to build confidence is to explore sensitivity. Change a boundary condition slightly, modify a material property, or alter a load, and see how the results respond. If small changes produce stable, consistent results, you know your model is robust. If tiny variations cause wild swings in output, you know your model is fragile and untrustworthy.

This habit not only builds confidence but also deepens understanding. By testing “what if” scenarios, you learn how loads travel, how geometry influences stresses, and how assumptions matter. The engineer who knows the sensitivity of their model is always more confident than the one who takes results at face value.

The Role of Peer Review and Mentorship

Confidence is not built in isolation. Having another engineer review your model can reveal blind spots you did not see. Mentors and peers bring fresh perspectives, catching mistakes in boundary conditions, mesh, or interpretation. More importantly, they provide reassurance when your approach is sound. Nothing builds confidence like hearing an experienced engineer say, “Yes, this setup looks correct.”

This is why mentorship is central to FEA practice. Left alone, young engineers may question themselves endlessly. Guided by a mentor, they learn which doubts are valid and which are unnecessary. Over time, this external validation becomes internal confidence.

Documenting Assumptions and Limitations

Confidence also comes from transparency. By clearly documenting your assumptions, what loads you applied, what simplifications you made, what effects you ignored, you build a record that others can review and trust. Paradoxically, admitting limitations strengthens credibility. When you say, “This model does not account for weld fatigue, but it accurately captures static stiffness,” you show you understand both the strengths and the boundaries of your work. Confidence is not about claiming perfection but about demonstrating clarity.

Conclusion: Confidence Through Rigor

Confidence in FEA does not come from trusting software defaults or producing colorful plots. It comes from rigor. It comes from grounding results in fundamentals, verifying setups, testing mesh convergence, interpreting results critically, validating against reality, exploring sensitivities, and seeking review.

Engineers who follow this path do not just run simulations; they deliver decisions. They can stand in front of managers, clients, or regulators and defend their results with authority. That authority is what transforms FEA from a technical exercise into a tool of engineering leadership.

At FEA Academy, we believe building confidence is as important as building skills. Our mentoring programs are designed to guide engineers step by step through this process, ensuring they not only know how to model but also how to trust and defend their results. Confidence is the ultimate outcome of good FEA practice. And with confidence, engineers can use simulation not just to analyze designs, but to shape the future of engineering itself.

Visit FEA Academy

In this second part of the series on FEM theory, I want to cover the solving aspect. If you missed the first part, it covered how the global stiffness matrix is assembled, illustrated for a simple flat plate discretized with four triangular CST elements. Here is the link to the first part: FEM Theory Part #1: How the Global Stiffness Matrix is Assembled?

In this second part of the series, we will look at how the solver computes the equation [K]{u} = {P}, which is the governing equation for a mechanical static problem.

Contrary to what you might expect, even though the unknown in this equation is the displacement vector {u}, and the stiffness matrix [K] and load vector {P} are known and defined by the analyst, the solver does not invert the stiffness matrix to compute the solution as {u} = [K]^-1{P}. The reason is efficiency: inverting a matrix that describes a problem with millions of degrees of freedom is computationally expensive and impractical.

The method used to solve the equation [K]{u} = {P} is known as the direct method based on LDLᵀ decomposition.

If like me you are curious about history, the method is attributed to André-Louis Cholesky, a French military officer and mathematician, who developed it around 1910 for geodetic survey calculations. He never published it himself; it appeared posthumously in 1924 (he died in World War I in 1918), credited to him by a colleague, Commandant Benoit. Alan Turing later made a separate contribution. In his 1948 paper “Rounding-Off Errors in Matrix Processes,” he gave the first elegant treatment of Gaussian elimination as a triangular decomposition (LU, and by extension LDLᵀ), along with an error analysis that became foundational to modern numerical linear algebra. Cholesky discovered the algorithm; Turing gave the framework it’s now presented within.

Three Steps

With the direct method, the equilibrium equation {P} = [K]{u} is solved for unknown displacements {u}, without inverting [K]. LDL^T decomposition, the matrix form of Gaussian elimination, is an efficient and accurate method, comprised of three steps:

• Step #1: Factorization, using the Cholesky decomposition

• Step #2: Forward Substitution

• Step #3: Backward Substitution

Let’s these three steps in detail.

Step 1: Factorization

Using the Cholesky decomposition, the stiffness matrix [K] is replaced by the product of three matrices: [L], [D] and [L]^T:

[K] = [L].[D].[L]^T

• [L] is the unit lower triangular matrix

• [D] is the diagonal matrix

• [L]^T is the unit upper triangular matrix

We can illustrate the factorization for a n x n matrix as follows:

The decomposition results in the stiffness matrix [K] being separated into the product of three simple matrices [L], [D] and [L]^T.

The decomposition process consists of finding the factors of [D] and [L]. To achieve that, the Cholesky method is used. Indeed, this method is very efficient in terms of memory storage capacity, computational cost, and speed. The Cholesky decomposition factors are computed as:

For i > j

Cholesky decomposition is implemented as follows:

1. The subscript i is the row index, and the subscript j is the column index.

2. Decomposition is computed column by column.

3. Decomposition starts with the evaluation of the diagonal terms in the column, using Equation 1

4. The other elements are evaluated row by row, using Equation 2

Step 2: Forward Substitution

Based on the factorization performed in step 1, the equilibrium equation can be written as:

[P] = [K]{u} = [L].[D].[L]^T{u} (Equation 3)

Let’s consider:

{y} = [D].[L]^T{u} (Equation 4)

Then, the Equation 3 becomes:

[P] = [L]{y}

where {y} is now the unknown.

We can compute {y}, starting with the first equation in the system [P] = [L] {y}

Starting from the first equation: f₁ = y₁

…and continuing with the next lines, using the results obtained from the previous lines:

f₂ = L₂₁.y₁ + y₂ ⇒ y₂ = f₂ - L₂₁.y₁

f₃ = L₃₁.y₁ + L₃₂.y₂ + y₃ ⇒ y₃ = f₃ - L₃₁.y₁ - L₃₂.y₂

… and so on. Therefore, the solution for {y} is (for i = 2 to n):

We calculated {y}.

Step 3: Backward Substitution

Now, let’s consider again the equation 4 above:

{y} = [D].[L]^T{u}

In this equation {u} is now the unknown.

It can be written as:

Using the results obtained for {y} during the Forward Substitution step, we can solve for {u} starting with the last equation:

For i = n, we have: y_n = D_nn.u_n

u_n is easily found by:

Then, moving backward {u} is solved by (for i = (n-1) to 1):

We know {u}.

Conclusion

As you can see, we solved the linear static problem without inverting the stiffness matrix, using only additions and multiplications through the Cholesky factors and Forward-Backward Substitution (FBS). This method is highly efficient in terms of computation time and memory usage, which is why all modern FEA solvers use it to perform linear static simulations. So the next time you see the messages “Stiffness Matrix Decomposition Performed” and “FBS Completed” in your log file, you will know exactly what the solver did in the background.

I have now sat through enough AI-in-engineering presentations to notice a pattern.

The slides are excellent. The vision is compelling. Somebody says “agentic” nine times. And at no point does anyone open a real model, on a real project, and show the thing working.

That is not a criticism of the technology. It is a criticism of how the technology is being presented. When a capability is only ever described and never demonstrated, engineers are right to assume it does not survive contact with a production project. We have all seen tools that worked beautifully on the vendor’s cantilever beam and fell apart on our assembly with 4,000 parts, three material databases, and a load set that changes every two weeks.

So I want to make an argument about where automation actually belongs in an FEA workflow, and then point you at a session where you can judge the claims yourself.

REGISTER FOR FREE TO THE SESSION

Where your week actually goes

Ask a structural analyst what they spent last week doing and the honest answer is rarely “analysis.”

It is chasing the current CAD version. It is finding out that the loads deck you were given is superseded. It is cleaning geometry that was never built for meshing. It is rebuilding a model you already built, because the configuration changed. It is re-running the same forty load cases you ran in June with one changed thickness. It is exporting results into a spreadsheet that feeds a template that produces a report that somebody will read for eleven minutes.

The solve, the part everyone thinks of as “the analysis,” is often the shortest step in the chain.

I have made this point before in a different context: the value an experienced analyst brings is not speed of execution, it is judgment. Deciding whether shell or solid is the right idealization. Knowing that a stress concentration at that fillet is a meshing artifact and not a finding. Recognizing that a result is converged and still wrong.

None of that is what eats the week. The week is eaten by the connective tissue around the judgment.

That is the honest case for automation in simulation, and it has nothing to do with replacing engineers. It is that a large fraction of a skilled analyst’s time is spent on work that is repeatable, deterministic, and auditable, which is exactly the profile of work a machine should be doing.

REGISTER FOR FREE TO THE SESSION

The line that matters

Here is the distinction I would ask any vendor to respect, and the one I use to evaluate every one of these tools.

Automate the workflow. Do not automate the judgment.

An agent can reasonably own: fetching the current geometry, applying a standardized cleanup recipe, generating a mesh to a documented set of controls, applying a load case matrix from a controlled source, launching the runs, extracting the quantities of interest, and assembling the results into the report template.

An agent should not own: deciding what to idealize, deciding what failure mode governs, deciding whether a result is credible, or deciding that something is fine.

The reason is not sentiment about the dignity of engineers. It is that the first list is verifiable and the second is not. You can check whether a mesh met its controls. You cannot check whether a modeling assumption was appropriate without exercising the same judgment you were trying to skip.

Any tool that blurs this line is selling you risk. Any tool that respects it is potentially giving you back two days a week.

Three questions for any demo

If you attend a demo of an agentic engineering tool, including the one I am about to recommend, these are the questions worth holding in your head.

1. Whose model is this?

Is it a real production project, or a curated example built to make the tool look good? Real projects have messy geometry, legacy assumptions, and inconvenient constraints. Demo models do not. The difference tells you almost everything about how much the demo is worth.

2. What happens when it is wrong?

Not if. When. Does the workflow surface the failure, or does it silently produce a plausible number? A tool that fails loudly is usable in an engineering organization. A tool that fails quietly is a liability, no matter how good it is on average.

3. Could you defend the output in a design review?

Can you trace every number back to an input, a version, and a decision? If the answer requires someone to say “the system generated it,” you do not have an engineering workflow, you have a black box with good manners.

Why I am pointing you at this one

Synera is running a live product demo on September 17, and the reason I am telling you about it is the format rather than the content.

Every demo in the session uses an actual customer workflow from an actual production project, with the customer’s IP stripped out. Not a purpose-built example. Not a slide about what would be possible in principle. The workflows they show are ones that engineers are running now, on work that ships.

That is the thing that has been missing from this entire conversation, and it is the only format in which the three questions above can actually be answered.

REGISTER FOR FREE TO THE SESSION

Speakers: Tehsinraza Mulla - Solution Engineer, Synera. Lorenz Flessner - Strategic Partnerships, Synera GmbH. Charles Lambert - Director of A&D, North America, Synera. Daniel Fuchshuber - Solution Engineer, Synera

If the timing does not work for you, register anyway. Registration gets you the recording, and I would rather you watch it late than not at all.

A note on what comes next

On September 29, Synera is running a second session with Aviation Week, this one featuring speakers from NASA and Airbus walking through aerospace use cases. That one is closer to home for most of you, and I will write about it properly in a couple of weeks.

Disclosure: The opinions here are my own. If the demo does not hold up, I will say so.

I decided to create a series of two articles dedicated to the Finite Element Method (FEM) theory. I’m writing this because I’ve been receiving many questions on the topic, and it also came up repeatedly in a survey I ran a few months ago, where I asked what topics you’d like me to cover.

Two subjects stood out: how the global stiffness matrix is assembled, and how the solver computes the linear equations.

So I’m kicking off this series on FEM theory, split into two parts:

FEM Theory Part #1: How Is the Global Stiffness Matrix Assembled?
FEM Theory Part #2: How Does Your FEA Solver Compute the Linear Problem Without Inverting the Stiffness Matrix?

The Equilibrium Equation

With the finite element method, a continuous system described by differential equations is represented by a discrete system called the mesh. The discrete system is a collection of elements connected at nodes. This process of discretization makes it possible to transform a real problem governed by partial differential equations, which cannot be solved by a computer, into a structural model governed by matrix equations that can be solved by a computer.

A structural problem with an infinite number of degrees of freedom is converted into a problem with a finite number of degrees of freedom. When the nodes are displaced, the elements have an elastic response within their domain, providing a representation of the elastic properties of the complete system.

For continuum mechanics problems, the unknown quantities of the mathematical model are the nodal displacements.

The finite element method is based on the following matrix equation, known as the General Equilibrium Equation of Mechanics, which defines the state of equilibrium of forces acting on a structure:

Since this article focuses on stiffness matrix assembly, we’ll assume the problem involves no dynamic effects. In other words, mass and damping are negligible, and the problem reduces to a static one. As a result, the general equilibrium equation above simplifies to:

[K]{u} = {P}

In this equation, the unknown is the displacement vector {u}, and we'll see in Part #2 how the solver computes the solution. The vector {P} represents the applied loads acting on the mechanical system, defined from all load types applied at the nodes (forces, pressure, enforced displacements, thermal effects, etc.). The stiffness matrix [K] is known and corresponds to the global stiffness of the mechanical system. This stiffness matrix is calculated at each node for the collection of degrees of freedom associated with each node, which themselves depend on the element formulation selected by the modeler.

Element & Global Stiffness Matrix

The chart below summarizes the process for generating the global stiffness matrix for a given problem. The first three stages fall under the analyst’s responsibility: creating the mesh and applying the geometric and material properties to the elements. The solver then takes over, with the computation of the stiffness matrices being one of its first tasks.

For each element composing the structural mesh, the stiffness matrix is computed in the element’s local axis and then transformed into a global coordinate system common to all elements.

The stiffness matrix is an inherent property of the structure: it is square and symmetric and includes only positive diagonal terms. Once the element stiffness matrices are calculated, they are assembled into a single global stiffness matrix based on how the elements are connected.

The stiffness at a given node is obtained by summing the stiffness contributions of all elements connected to that node. Assembling the global stiffness matrix therefore consists of placing each element’s degrees of freedom in their proper position within the global stiffness matrix of the whole structure (I’ll illustrate this later with an example).

Which Parameters Influence the Element Stiffness Matrix?

The stiffness matrix is affected by several parameter:

• The type of elements selected by the analyst and their formulations

• The material properties assigned to the elements

• The mesh quality

• The boundary conditions

• The connections between elements

Keep in mind that these parameters, as defined by the analyst, are critically important, because the stiffness matrix computation allows us to answer several key questions:

• Where is the structure stiff and where is it flexible?

• How are the loads distributed among the different components of the structure?

• Which parts move when external loads are applied on the structure and how much do they move?

The Generic Form of the Element Stiffness Matrix

In Chapter 5 of my book, Practical Finite Element Analysis for Mechanical Engineers, I present the fundamentals of FEM theory, including how element stiffness matrices are computed for 1D, 2D, and 3D elements. You can also find these details in my article “The Finite Element Theory in Depth” available on the FEA Academy website.

For this article, however, I’ll simply remind you that the following equation, derived from the virtual work principle, allows us to compute the element stiffness matrix for any element used in a finite element model:

where:
[B] is the Strain-Displacement Matrix. The form of [B] depends on the shape function used to describe the displacement field in the element.

[D] is the Constitutive matrix (related to the material data)

Global Stiffness Matrix Assembly

To explain how the global stiffness matrix is assembled by the solver, I am going to take a simple example. Let’s consider a simple rectangle plate discretized using four constant strain triangular (CST) elements, as shown on the figure below:

Six nodes are involved in this discretization.

Each CST element has two degrees of freedom at each node, so the total number of degrees of freedom for the plate is 6 x 2 = 12.

Then, the stiffness matrix for the plate meshed with four CST elements will have a size of 12 x 12.

As mentioned at the beginning of this article, the assembly of elements consists of placing each elemental matrix in the appropriate position within the global matrix, based on the degrees of freedom associated with each element.

The element stiffness matrices for each CST elements are computed numerically by the FE solvers, using the geometrical and material data assigned to each element.

Let’s see what the solver is doing element by element.

Element #1

Element #1 is connected at nodes #1, #4, and #5. The degrees of freedom involved in constructing the stiffness matrix for element #1 are: (u1, v1), (u4, v4), and (u5, v5). So, we know that the stiffness matrix for element #1 is written as (note that the nodes are considered anti-clock wise):

So, for the element #1, the global stiffness matrix is populated as:

Element #2

Element #2 is connected at nodes #1, #2, and #5. The degrees of freedom involved in constructing the stiffness matrix for element #2 are: (u1, v1), (u2, v2), and (u5, v5). So, we know that the stiffness matrix for element #2 is written as (note that the nodes are considered anti-clock wise):

So, for the element #2, the global stiffness matrix is populated as:

Element #3

Element #3 is connected at nodes #2, #3, and #5. The degrees of freedom involved in constructing the stiffness matrix for element #3 are: (u2, v2), (u3, v3), and (u5, v5). So, we know that the stiffness matrix for element #3 is written as (note that the nodes are considered anti-clock wise):

So, for the element #3, the global stiffness matrix is populated as:

Element #4

Finally, the element #4 is connected at nodes #3, #5, and #6. The degrees of freedom involved in constructing the stiffness matrix for element #4 are: (u3, v3), (u5, v5), and (u6, v6). So, we know that the stiffness matrix for element #4 is written as (note that the nodes are considered anti-clock wise):

So, for the element #4, the global stiffness matrix is populated as:

Assembly

The figure below shows the assembly of the elements with their associated degrees of freedom (u_i,v_i) for i = 1 to 6.

• Half of the positions in the matrix have null values.

• The stiffness matrix is symmetric.

• Only the upper portion of the stiffness matrix must be computed and stored to perform the structural analysis.

The global structure stiffness matrix [K] for the rectangle plate meshed with four constant strain triangular elements is obtained using the direct stiffness method:

Now you know how your FEA solver assembles the complete stiffness matrix for your finite element model. In the second part of this series on FEM theory, we’ll look at how your FEA solver computes the linear problem without inverting the stiffness matrix.

Subscribe now

If you have felt that moment, you are not behind. You are paying attention.

Subscribe now

The myth that keeps analysts stuck

Early in a career, it is easy to believe that expertise means knowing everything. Every solver option. Every element formulation. Every edge case in contact convergence. So when something unfamiliar comes up, the instinct is to feel like a fraud rather than like someone doing exactly what the job requires.

This belief is not just wrong, it is quietly harmful. It pushes analysts toward two bad habits: either they freeze up on anything unfamiliar, or they push forward without pausing to question a result that deserves more scrutiny.

The truth is simpler and more useful. No one holds the entire field of FEA in their head. Not the senior fellows, not the people writing the textbooks, not the people teaching the courses. What separates a competent analyst from a dangerous one is not the size of their knowledge base. It is their instinct for what needs checking, and when.

What “knowing what to check” actually looks like

This is judgment, not memorization. A few examples of what it looks like in practice:

Boundary conditions before mesh refinement. When a model gives an unexpected result, the instinct to refine the mesh is often premature. Before touching element size, an analyst who knows what to check asks whether the boundary conditions actually represent the physical constraint, and whether a rigid connection is hiding a load path that should be flexible.

Energy balance over visual plausibility. A stress plot can look completely reasonable and still be wrong. Checking internal versus kinetic energy ratios in a nonlinear or dynamic run, or reviewing residual force balance in a static solve, catches problems that a color contour will never reveal.

Units and scale, every single time. This sounds too basic to mention, and that is exactly why it causes so many quiet failures. A displacement that is off by a factor of 25.4 does not always look wrong at first glance. The habit of checking units is not a beginner’s habit, it is a lifelong one.

Where the model diverges from the real structure. Every model is a simplification. Knowing what to check means being honest about which simplifications matter for the question being asked, and which ones do not.

None of this requires knowing every corner of the software. It requires a disciplined habit of asking the right questions in the right order.

A story worth remembering

Early in my career, I once trusted a result because everything about it looked clean. Smooth contours, no error messages, a load path that seemed to match the drawing. It was only when a colleague asked me to walk through the boundary conditions out loud that I realized a constraint meant to represent a bolted joint was fully fixed instead of allowing rotation. The model was not wrong because I lacked knowledge. It was wrong because I had not yet built the habit of pausing before trusting a clean-looking answer.

That habit did not come from a course. It came from being asked the right question at the right moment, and from repeating that question to myself on every project since.

Where this leaves you

If you are early in your FEA career and feel like you are constantly catching up, you are not missing some hidden body of knowledge that everyone else has. You are building a habit of scrutiny, and that habit takes time and repetition, not memorization.

If you are further along and still second-guess yourself in front of a results plot, that instinct is not a weakness. It is the same instinct that keeps good analysts good.

The goal was never to know everything. The goal is to know what deserves a second look, and to have the discipline to look.

What is the check that saved you on a project, or the one you wish you had made earlier?

That answer is easy to say and hard to act on, because the conversation around AI in simulation is polluted by two extremes. On one side, vendors and enthusiasts promise that you will soon describe a part in plain English and receive a certified stress report thirty seconds later. On the other side, veterans dismiss the whole thing as a fad, the same way some dismissed FEA itself in the 1970s. Both camps are wrong, and both are wrong in ways that can hurt your career.

So let me give you an honest assessment, based on what I see in the industry today, of what AI can do in FEA right now, what it cannot do, and where the line is likely to move.

Subscribe now

What AI can do today

Accelerate the tedious parts of the workflow. The unglamorous truth of our profession is that a large fraction of an analyst’s week is not analysis. It is writing scripts to extract results, formatting load tables, cleaning up geometry, renaming files, documenting assumptions, and drafting reports. Modern language models are remarkably good at this layer. They write Python, DMAP snippets, APDL macros, and scripts faster than most engineers, and they explain error messages that used to cost you an afternoon of forum searching. If you are still manually copying reserve factors into a spreadsheet, you are leaving hours on the table every week.

Act as an interactive reference. A well-prompted AI assistant is like having a colleague who has read every textbook and every manual, and who never gets tired of your questions. Ask it why your contact analysis is not converging, and it will list the usual suspects: initial penetration, insufficient stabilization, an overly aggressive first increment. Ask it to explain the difference between shear locking and hourglassing, and you will get a solid answer. This is a real productivity gain, especially for engineers early in their careers who do not yet have a mentor down the hall.

Build surrogate models. This is, in my view, the most mature and most underappreciated application of machine learning in simulation. Once you have run a few hundred FEA solutions across a design space, you can train a surrogate that predicts stress, stiffness, or margins in milliseconds instead of hours. For optimization loops, trade studies, and digital twins, surrogates are already delivering value in aerospace and automotive programs. They do not replace the finite element method; they are built on top of it.

Assist with pre-processing. Tools are emerging that suggest mesh settings, detect thin features, propose mid-surface extraction, and flag geometry that will cause element quality problems. Some of this is classical automation dressed in AI clothing, but the direction is clear: the mechanical labor of meshing is shrinking, and that is a good thing. Nobody’s engineering value ever came from manually splitting faces for a structured mesh.

Review and critique. Give a capable model your analysis summary and ask it to challenge your assumptions, and it will often catch things: a boundary condition that over-constrains the structure, a load case you did not consider, a units inconsistency. It is not a substitute for a checker, but it is a useful first filter before your work reaches one.

What AI cannot do today

Take responsibility. This is the fundamental limitation, and it is not a technical one. When an analysis supports a certification decision, someone signs it. That signature means a person with recognized competence has judged the model adequate for its purpose, and that person is accountable if it is not. No AI system can carry that accountability, and no certification authority accepts “the model said so” as substantiation. Until the regulatory and legal framework changes, and I see no sign of that happening soon, the human signature remains the anchor of the entire process.

Know when the model is wrong for reasons the model cannot see. An AI can check your inputs against your inputs. It cannot know that the supplier changed the heat treatment last month, that the fitting in the drawing is not the fitting on the shop floor, or that the load case handed to you by the loads group contains an error upstream. FEA is embedded in a physical and organizational reality that lives outside any dataset. Judging whether an idealization represents that reality is precisely the skill I call engineering judgment, and it is built from exposure to hardware, test failures, and consequences. Current AI has none of that exposure.

Guarantee correctness. Language models are confident by design. They will explain a wrong answer with the same fluency as a right one. In a domain where a misplaced constraint can hide a factor of two in stress, fluent wrongness is dangerous. Every output, whether it is a script, a recommended element type, or an interpretation of results, must be verified by someone competent to verify it. If you cannot check the answer, you are not ready to use the tool.

Replace verification and validation. There is no shortcut here. Mesh convergence, sanity checks against hand calculations, comparison with test data, free body diagrams that close: these remain the backbone of credible simulation. AI can help you execute them faster. It cannot make them optional.

Handle the novel case. Machine learning is interpolation at heart. Surrogates are excellent inside the design space they were trained on and unreliable outside it. The most consequential engineering questions, the new architecture, the unusual failure mode, the configuration nobody has flown before, are by definition outside the training data. That is exactly where physics-based analysis and experienced judgment matter most.

Where the line is moving

The line between the two lists above is not fixed. Three shifts seem likely to me over the next few years. Agentic workflows will chain tasks together, so instead of asking for a script, you will ask for a mesh sensitivity study and receive one, executed end to end. Physics-informed machine learning will make surrogates more trustworthy near the edges of their training space. And AI-assisted checking will become standard practice, with models systematically screening analyses for common errors before human review.

Notice what all three have in common: they compress the execution layer of our work. None of them touches the judgment layer. The decisions about what to analyze, how to idealize it, what the results mean, and whether they can be trusted move closer to the center of the job, not further from it.

What this means for you

If you are early in your career, do not let AI do your thinking while your fundamentals are still forming. Use it to learn faster, but solve the beam bending problem by hand first, because the day the AI is wrong, your hand calculation is the only thing standing between you and a bad release. If you are experienced, resist the temptation to dismiss these tools. Your judgment is the scarce asset, and AI is a lever that multiplies it. An expert with good tools outperforms an expert without them, every time.

The finite element method did not eliminate stress engineers; it eliminated stress engineers who refused to learn it, and it made the ones who mastered it far more valuable. AI is following the same script. The tools will keep getting better at execution. The engineers who thrive will be the ones who keep getting better at judgment.

That has always been the deal in this profession. AI has not changed it. It has raised the stakes.

The mistake that costs millions is this: trusting the model instead of questioning it.

After more than two decades of aerospace structural analysis, I can tell you that I have never seen a program derailed because someone used a 5 mm mesh where a 3 mm mesh would have been better. But I have seen programs bleed money, schedule, and credibility because an analyst produced a beautiful, converged, colorful result that answered the wrong question, and nobody in the room had the judgment to notice.

Subscribe now

The Seduction of the Contour Plot

Modern FEA software is remarkable. It is also seductive in a way that older engineering tools never were. A slide rule did not produce a rainbow-colored stress plot. A hand calculation on a notepad did not render a deformed shape in smooth animation. When your tool produces something that looks like an answer, it takes discipline to remember that it might not be one.

This is the core problem. A finite element model always produces a result. It never refuses to run because your boundary conditions are physically meaningless. It never pauses to ask whether the load case you applied actually represents the worst case the structure will see in service. It computes exactly what you told it to compute, with impressive precision, and then presents it with a confidence that the underlying assumptions may not deserve.

Mesh refinement makes this worse, not better, when judgment is absent. A finer mesh produces a more precise answer to the question you asked. If the question was wrong, you now have a very precise wrong answer, and the precision itself becomes an argument for believing it. I have watched review boards nod along to a stress result because the convergence study was rigorous, while the fundamental load path assumption sitting underneath the entire model went unexamined.

Where the Millions Actually Go

Let me be concrete about how this failure mode turns into money.

The first way is overdesign. An analyst builds a model with conservative assumptions stacked on conservative assumptions: worst-case loads, minimum material properties, a fitting factor here, an uncertainty factor there. Each one is individually defensible. Together they produce a structure that is 30 percent heavier than it needs to be. In aerospace, every kilogram of structural weight is paid for in fuel, payload, or performance over the entire life of the vehicle. Nobody writes a failure report for overdesign. It never makes the news. It just quietly costs millions, forever, and the analyst who caused it gets praised for being thorough.

The second way is the late surprise. A model that misrepresents the real load path, the real stiffness distribution, or the real failure mode sails through analysis reviews because it is well-meshed and well-documented. The problem surfaces in qualification testing, or worse, in service. Now you are redesigning under schedule pressure, requalifying, retrofitting, and explaining to a customer why the analysis did not catch it. A structural redesign discovered at the test stage routinely costs ten to a hundred times what it would have cost to catch on paper. Discovered in service, add another order of magnitude, plus the reputational damage that never fully appears on any invoice.

The third way is the slowest and the most expensive of all: the erosion of trust in analysis itself. When simulation results are wrong often enough, organizations respond by adding testing, adding margins, and adding review cycles. The entire value proposition of simulation, which is to reduce physical testing and accelerate development, quietly collapses. Companies end up paying for both the analysis and the testing they were supposed to avoid, because nobody trusts the analysis enough to act on it.

None of these failure modes is fixed by a finer mesh. All of them are fixed by judgment.

What Judgment Actually Looks Like

Engineering judgment is often described as if it were mystical, something that simply accumulates after enough years in the field. I disagree. Judgment is a set of concrete habits, and they can be taught, practiced, and evaluated. Here is what they look like in an FEA context.

Judgment means estimating the answer before you compute it. A back-of-the-envelope calculation, a simplified beam model, a comparison to a similar structure you analyzed last year. If your model returns a stress three times higher than your hand estimate, one of the two is wrong, and finding out which one is where the real engineering happens. An analyst who cannot predict the order of magnitude of the result before pressing solve is not analyzing. They are gambling with a very expensive random number generator.

Judgment means interrogating boundary conditions harder than element quality. In my experience, boundary conditions and load introduction are responsible for more wrong answers than every meshing error combined. A fixed constraint where the real structure has flexibility. A point load where the real interface distributes pressure. These modeling decisions can shift results by factors, not percentages, and no mesh refinement study will ever reveal them, because the refined model converges beautifully to the wrong physics.

Judgment means knowing what the model is for. A model built to predict global load distribution should not be mined for local peak stresses. A linear model should not be quoted in a region where the material has clearly yielded. Every model has a domain of validity, and the analyst’s job is to know its edges and to say, out loud, when a question falls outside them. Some of the most valuable sentences in engineering begin with the words “this model cannot answer that.”

Judgment means treating a surprising result as a question, not a conclusion. When the stress is unexpectedly low, the weak analyst is relieved and the strong analyst is suspicious. Surprises are where models reveal either something true about the structure or something broken about the assumptions, and you do not get to know which until you dig.

The Uncomfortable Implication for How We Train Analysts

Here is what troubles me about how our field develops its people. We train software operation and call it FEA training. A young engineer learns which buttons to press, which element types to select, which convergence criteria to check. All useful. None of it addresses the actual failure mode.

The industry has effectively outsourced the easy part of analysis to the software and kept the hard part for the human, then trained the human on the easy part. Solvers have never been more accurate. Meshing has never been more automated. The remaining source of catastrophic error is, overwhelmingly, the person making the modeling decisions and interpreting the output. That is precisely the layer where most training is thinnest.

This will only become more true, not less. As AI-assisted tools take over more of the mechanical work of model construction, the value of an analyst will concentrate entirely in the things software cannot do: framing the right question, choosing assumptions that reflect reality, recognizing when an answer cannot be trusted, and communicating what the results mean for a decision. The engineers who invest in judgment are building a career on the one asset that automation makes more valuable. The engineers who invest only in tool proficiency are competing with the tool.

The Mistake, Restated

So the one FEA mistake that costs millions is not a meshing error, and it never was. It is the transfer of responsibility from the engineer to the model. It is the moment an analyst stops asking “is this physically reasonable?” and starts asking only “did it converge?”

Convergence tells you the mathematics is settled. It tells you nothing about whether the mathematics describes your structure. That verdict belongs to the engineer, and it always will.

Refine your judgment first. The mesh can wait.

Share

Most of us begin with linear analysis. It’s fast, efficient, and works well for many everyday problems. But in real-life applications, structures don’t always behave linearly - and ignoring that can lead to misleading results.

What is a Nonlinear System?

Mathematically speaking, a nonlinear system is one whose behavior is not equal to the sum of its parts. Therefore, the behavior of a nonlinear system does not satisfy the principle of superposition. In a linear analysis, it is assumed that the response of the structure (deformation, internal loads, or stresses, etc.) is linearly proportional to the applied loads. However, in real life, this response may not be linearly proportional to the applied load and then the structure must be analyzed using nonlinear assumptions. In linear static analysis, the stiffness [K] of the analyzed structure is assumed to be constant.

In the real world, it is very likely that a structure will behave in a nonlinear manner, for geometrical, material, or boundary reasons. Indeed, the stiffness of the structure is based on its geometry and material properties. In a linear analysis, these parameters are assumed to be unchanged while the loading is applied. In a nonlinear analysis, these changes are taken into account, and the stiffness matrix is updated using the deformed structure’s configuration, after each incremental load application

Characteristics of a Nonlinear System

LOAD-DISPLACEMENT RELATION
The stiffness of the analyzed structure is not constant and varies with the applied loads. The displacements are large (translations and rotations) and are not related to the original stiffness of the structure.

STRESS-STRAIN RELATION
Stresses and strains are not related to a linear function.

SCALABILITY
The results of a nonlinear analysis cannot be scaled.

SUPERPOSITION
The principle of superposition cannot be applied. If a load P1 produces a displacement d1 and a load P2 a displacement d2, then the load P1 + P2 will not cause a displacement d1 + d2.

INITIAL STATE OF STRESS
The initial state of stress (residual stresses, temperature, pre-stressing) may be extremely important in the overall response.

LOAD HISTORY
The structure’s response is related to the load history: it is influenced by the loading sequence. When several subcases are applied in sequence in the structure, the end of a subcase is the initial condition for the next subcase.

REVERSIBILITY
The deformation of the structure is not fully reversible once the applied loads are removed.

SOLUTION SETTINGS
The external loads are applied in small increments, and iterations are performed to ensure that equilibrium is satisfied at each load increment. Solution monitoring by the user is required to ensure convergence. The computing time is usually large. While linear problems always have a unique solution, a nonlinear problem might not. In fact, the iterative and incremental processes used to solve nonlinear problems may not converge and may even produce an incorrect solution at convergence.

The Three Types of Nonlinearity

In structural analysis, a nonlinear effect can occur because of three types of nonlinearity:

• Geometric nonlinearity: if a continuous body undergoes large deformations, the strain-displacement relations become nonlinear. Moreover, under large deformations, the stiffness of the system will change with deformation, making the problem nonlinear.

• Material nonlinearity: if a material does not follow Hooke’s law, nonlinear material models must be used.

• Boundary nonlinearity: the most frequent boundary nonlinearities are encountered in contact problems.

Nonlinear Geometric

Under large deformation, the deformed structure has a different geometry, implying a changing stiffness. The stiffness matrix [K] is a function of displacements {u}.

{P} = [K(u)]{u}

Under large deformation, the deformed structure has a different geometry, implying a changing stiffness. The stiffness matrix [K] is a function of displacements {u}.

Criteria for Triggering Nonlinear Geometric (Large Displacement) Analysis

The fundamental question is: when do displacements become large enough that the deformed geometry differs meaningfully from the undeformed geometry?

The Classic Rule of Thumb

If the maximum displacement exceeds roughly 5–10% of a characteristic structural dimension, geometric nonlinearity should be considered.

However, that characteristic dimension is context-dependent. Let’s see in detail how it works.

What "Characteristic Dimension" Means in Practice

Physical Reasoning Behind the Criterion

Linear (small displacement) theory assumes:

• The equilibrium equations are written on the undeformed geometry.

• Strains are approximated as infinitesimally small (Green-Lagrange tensor reduces to engineering strain).

• The stiffness matrix K remains constant throughout loading.

Geometric nonlinearity becomes significant when one or more of these assumptions breaks down:

1. Membrane-bending coupling - out-of-plane deflection induces in-plane membrane forces that stiffen or soften the structure (e.g., drum skin, pressure vessel).

2. Follower forces - applied loads rotate with the structure (pressure on a curved shell).

3. P-delta effect - axial load acting through a lateral displacement generates a destabilizing moment.

4. Stress stiffening / softening - pre-tension stiffens, compressive load softens (buckling precursor).

More Rigorous Engineering Indicators

Rather than a single displacement ratio, experienced analysts watch for:

• Rotation angle > ~5–10° - the small-angle approximation (sin θ ≈ θ) degrades beyond this.

• Strain > ~1–2% - although this is often the material nonlinearity trigger, it coincides with geometry effects in metals.

• Load-deflection linearity check - if doubling the load does not roughly double the deflection in a linear run, geometric nonlinearity is active.

• Proximity to buckling - if the applied load is more than ~10–20% of the linear buckling load (eigenvalue from SOL 105), geometric nonlinearity must be included.

• Slenderness - very slender members (high L/r or L/t ratios) are inherently displacement-sensitive; the threshold drops significantly.

Summary table

The Honest Answer for Engineering Practice

No single ratio is universally authoritative. The 5–10% of span rule is a screening criterion, not a physics boundary. The actual transition is gradual, and the correct approach remains the sensitivity study: if activating the large displacements option changes your peak displacement or stress by more than your required accuracy tolerance, the linear assumption was invalid regardless of what ratio you computed.

What matters most is developing the instinct to ask the question early, before post-processing, based on structural topology and loading type.

Nonlinear Material

The stiffness response depends on deformation. The stiffness matrix [K] is a function of displacements {u}.

{P} = [K(u)]{u}

Boundary Nonlinearity

Boundary conditions changing with deformation: the size c of the contact surface and the contact load Rc depend on deformation and load. The stiffness matrix [K] and loading {P} are functions of displacements {u}.

{P(u)} = [K(u)]{u}

When Do You Really Need to Run A Nonlinear Analysis?

Nonlinear analysis demands more computing time and expertise, so it’s important to know when it’s truly required.

If you answer “yes” to one of the following questions, you should go with a nonlinear analysis:

• Does the structure deform significantly?

• Does the structure exhibits stress stiffening (tension-bending coupling in a membrane under pressure for example)?

• Do the stresses exceed the proportional limit?

• Does the stiffness of the structure change when a loading is applied?

• Do you expect to capture contact conditions (engaged or disengaged) between some components of you model?

If one of the five questions above made you hesitate about a model you are running right now, that hesitation is worth investigating. In the comments, I would like to hear which nonlinearity gives you the most trouble: geometry, material, or contact.

The Setup

I was a young stress engineer, only a few years into the job, when I was given responsibility for a highly loaded fitting: a machined aluminum lug assembly transferring load from a control surface actuator into the surrounding structure through a pinned connection. Nothing exotic. Every aerospace stress engineer has analyzed a dozen of these. The classical hand calculations were done, the margins looked healthy, and the detailed FEA was supposed to be a formality to confirm the peak stress location and justify the fatigue analysis.

Because the load path went through a pin bearing against a lug bore, this was, by definition, a contact problem. I built a solid model of the lug, the pin, and the mating clevis. I defined contact between the pin and the bore surfaces, applied the actuator load, and ran the nonlinear solution.

It converged beautifully. Clean load increments, no cutbacks, tidy contact pressure distribution over roughly 40 degrees of the bore. The peak stress sat exactly where the hand calculations said it should, at the net section adjacent to the hole. The FEA result even came in slightly below the classical bearing solution, which I interpreted as the model capturing beneficial load redistribution that the conservative hand methods ignored.

I wrote the report. The margins were positive. Everyone was happy.

Subscribe now

The Phone Call

Months later, the static test article went into the rig. The test plan called for loading to limit, then to ultimate, with strain gauges bonded around the lug. At about 85 percent of limit load, one of the gauges near the bore was reading almost 30 percent higher strain than my model predicted. Not a calibration issue. Not a bad gauge. Two adjacent gauges confirmed the trend.

I remember the phone call from the test lab vividly. There is a particular feeling in your stomach when measured data disagrees with your model in the unconservative direction. A model that overpredicts stress is an economics problem. A model that underpredicts stress is a safety problem, and it is yours to own.

That night I did not sleep. I kept replaying the analysis in my head, looking for the error. Mesh density? I had done a convergence study on element size. Material properties? Standard MMPDS values, checked twice. Boundary conditions? Reviewed by a colleague. Load introduction? Straight from the loads group. Everything individually looked defensible. And yet the structure was telling me, in strain gauge readings that do not care about my report, that my model was wrong.

The Hunt

The next morning I started over, and this time I did what I should have done at the beginning: I interrogated the contact solution itself instead of just admiring the fact that it converged.

The first thing I checked was the contact pressure distribution, and this time I looked at it critically rather than approvingly. The contact patch was suspiciously wide and suspiciously smooth. Real pin-in-hole contact with a clearance fit produces a narrow, concentrated bearing footprint, especially at lower loads before the pin beds in. My model showed the pin engaging the bore almost like a press fit.

Then I found it. Two modeling decisions, each defensible on its own, had combined into one wrong answer.

First, the geometry. The CAD model I had received represented the pin and the bore at nominal identical diameters. Line-to-line contact. The real hardware had a specified clearance fit, small in absolute terms, a few thousandths of an inch, but enormous in its effect on contact mechanics. With zero clearance, the pin engages a wide arc of the bore immediately and the bearing pressure spreads out. With realistic clearance, the pin contacts over a much smaller arc, the peak bearing pressure climbs, and the tangential stress at the edge of the contact patch rises with it. I had analyzed a different joint than the one being tested.

Second, the contact stiffness. To help convergence during early debugging runs, I had softened the contact penalty stiffness. The run converged faster, and I never restored the value. Soft contact allowed additional penetration, which artificially widened the contact patch even further and smeared out the pressure peak. The solver was perfectly happy. The physics was not.

Put those two together and the model was quietly redistributing load in a way the real structure could not. My beautiful converged solution was a precise answer to the wrong problem.

The Fix, and the Real Lesson

The correction itself was straightforward. I rebuilt the model with the actual clearance from the drawing, restored a properly stiff contact formulation, verified penetration was negligible compared to the clearance dimension, and reran the load steps. The predicted strains moved to within a few percent of the gauges. The peak stress location shifted slightly around the bore, exactly where the test article would later show fretting marks. The margin dropped but remained positive after a refined analysis, and the program moved on. On paper, a happy ending.

But the lesson was never about penalty stiffness or clearance fits. Those are just this story’s particular details. The lesson is this: in contact analysis, convergence is a statement about the mathematics, not about the mechanics. The solver converged because I had, step by step, made the problem easier to solve. Every simplification pushed in the same direction, toward a softer, smoother, more forgiving joint. None of them triggered an error message. Contact problems fail silently. They hand you a plausible looking answer and let you decide whether to question it.

What saved the program was not my model. It was the strain gauges. That reversed my thinking permanently: the test did not validate my analysis, it corrected it. Since that day, I treat every contact model as guilty until proven innocent, and I make the model prove itself through checks that do not depend on the solver’s opinion of its own convergence.

What I Do Differently Now

Three habits came out of that sleepless night, and I have taught them to every engineer I have mentored since.

First, I sanity check the contact solution against classical mechanics before I believe anything else in the model. Hertzian contact estimates, bearing stress distributions from lug analysis methods, contact arc predictions as a function of clearance. If the FEA contact patch does not resemble what 100 years of contact mechanics says it should look like, the FEA is wrong until demonstrated otherwise.

Second, I audit every numerical convenience before the final run. Softened penalty stiffness, adjusted initial gaps, contact stabilization, artificial damping. These are legitimate debugging tools, and they are also legitimate sources of wrong answers. Anything I added to make the solver’s life easier gets removed or quantified before results go into a report.

Third, I model the hardware, not the CAD. Nominal geometry is a fiction. Clearances, tolerances, and fits are not manufacturing trivia; in contact problems they are often the dominant physics. If a fit dimension can change my contact patch, it goes into the model, ideally at both tolerance extremes.

I got this wrong once, and I was fortunate that a test article and a few strain gauges caught it before anything worse did. The software has improved enormously since then. The failure mode has not. Contact analysis still rewards the engineer who questions a converged solution and still punishes the one who admires it. If my sleepless night saves you one of your own, this story has done its job.

Share

Neither is true. In an FEA role, hand calculations do not mean working without computers. They mean something more important: being able to reason about a structure independently of the software, so that when the software gives you an answer, you know whether to believe it.

After 25 years of building and reviewing FEA models in aerospace, I consider this one of the clearest markers separating engineers who run simulations from engineers who understand them. Here is what the skill actually involves, and how to build it.

Subscribe now

Why hand calculations matter in an FEA role

There are four reasons this skill appears in job descriptions, and all four come from real engineering practice rather than tradition.

The first is verification of FEA results. Simple formulas, beam theory being the classic example, let you check a simulation against an independent reference. When the hand calculation and the model disagree by an order of magnitude, one of them is wrong, and finding out which one catches errors in setup or assumptions before they become expensive.

The second is preliminary design estimation. Before any detailed modeling begins, quick hand calculations tell you whether a concept is feasible and shape how you should approach the simulation in the first place. A model built after a rough analytical pass is almost always a better model.

The third is structural behavior insight. Working through calculations by hand builds intuition about load paths, constraints, and material response. That intuition is exactly what you rely on when a simulation produces a result that looks wrong and you need to figure out why. You cannot debug a model using only the model.

The fourth is certification and client trust. In industries like aerospace and automotive, regulatory bodies often require analytical justifications alongside simulation results. A hand calculation is transparent in a way a model is not: anyone can follow it, check it, and challenge it. That transparency builds trust and meets compliance requirements.

The calculations you are expected to know

The expectation is not exotic mathematics. It is fluency with the classical toolkit of structural analysis:

- Axial loading: stress equals force over area

- Bending of beams: Euler-Bernoulli or Timoshenko theory

- Shear and torsion: shear stress in shafts, shear flow in thin-walled sections

- Pressure vessels: hoop and longitudinal stresses

- Buckling of columns: Euler’s critical load

- Vibration: natural frequency of single-degree-of-freedom systems

None of these is advanced on its own. What matters is being able to reach for the right one quickly, apply it with sound assumptions, and know what its simplifications hide.

How to build the skill

If you recognize a gap here, it closes with deliberate practice rather than talent. Four things work.

Start with the right references. Roark’s Formulas for Stress and Strain remains the gold standard for analytical methods. Mechanics of Materials by James Gere covers the foundations, and Shigley’s Mechanical Engineering Design is excellent for machine elements.

Then practice against your own tool. Work through beam problems, pressure vessel shells, joints, lugs, and brackets, and compare your analytical results with simple 1D and 2D FEA models. This comparison is where the real learning happens, because it forces you to explain every discrepancy.

Build a personal handbook as you go. Keep a notebook or PDF of the formulas you use, solved examples, assumptions, and material properties. Over a career, this becomes one of your most valuable tools.

Finally, understand the limitations. Hand calculations rest on simplifications: linear elasticity, ideal constraints, idealized geometry. Knowing when those simplifications break down is as much a part of the skill as the calculations themselves.

The real meaning of the requirement

When a job posting asks for hand calculations, it is asking whether you can independently validate simulation results, estimate mechanical behavior with confidence, and communicate your assumptions and justifications clearly.

It is a sign of maturity, judgment, and engineering integrity. The software will keep getting more powerful. The engineers who stand out will be the ones who never needed it to tell them what to think.

If there is a hand calculation you reach for constantly in your own work, or one you think every FEA engineer should know, I would like to hear it in the comments. This is exactly the kind of skill that improves fastest by comparing notes.

Share