
By Dr. Barna Szabó
Engineering Software Research and Development, Inc.
St. Louis, Missouri USA
As incredible as it may sound, the core technology and supporting architecture implemented in legacy finite element software are nearly 60 years old. As a consequence, several important results developed since then have not been made available to engineering users of these tools.
In my previous blog posts, I have consistently distinguished between the art of finite element modeling and the science of finite element analysis. These can be viewed as two evolutionary lineages that developed virtually independently. The art of finite element modeling is rooted in the 1960s, a period that falls within the early, pre-paradigmatic phase of the development of the finite element method. This phase, as defined by Thomas Kuhn, refers to a period before a field of scientific inquiry had a unified theoretical framework [1].
The development of a unified theoretical framework for the finite element method occurred later, reaching a high level of maturity by the end of the 1980s. This framework emerged primarily within the mathematical community, where the finite element method was viewed as a numerical technique for approximating the exact solutions of well-posed mathematical problems. In contrast, the engineering community — including the developers of commercial finite element codes — regarded the method as an intuitive modeling tool, essentially an extension of the matrix methods of structural analysis [2].
This historical divergence is the primary reason numerical simulation still holds substantial unrealized potential. That potential arises from a disconnect between the professional practice of finite element modeling and the underlying science of numerical simulation. Unlocking it requires bridging this gap—a challenge that demands overcoming several critical obstacles.
Mixed Performance
By the time the theoretical foundations of the finite element method had matured, legacy commercial codes had already become deeply embedded in engineering workflows. Over the past fifty years, practitioners have accumulated a substantial body of experience with these tools. The results, however, have been mixed.
These codes have been used effectively for structural analysis problems, such as airframe load modeling and automobile crash dynamics. In such cases, the quantities of interest are primarily load–displacement responses, which require only reasonably accurate element stiffnesses—a goal that can be achieved through judicious choice of input data and tuning. Strength analysis, by contrast, is far more demanding. It depends on stresses and other quantities derived from the derivatives of the displacement field. Reliable stress prediction, therefore, requires a more accurate representation of the displacement field and far greater care in modeling details. For example, concentrated forces, point constraints, and reduced-integration elements must be avoided.

Despite decades of use, legacy finite element codes cannot deliver decision-grade reliability in strength predictions. Explaining the primary cause of massive project delays and cost overruns in the F-35 program, Acting Undersecretary of Defense (later Air Force Secretary) Frank Kendall said, “the department made optimistic predictions when we started the production of the F-35, that we now had good enough design tools and good enough simulations and modeling that we wouldn’t have to worry about finding problems in tests. That was wrong, and now we’re paying the price” [3].
These “optimistic predictions” were based on the assumption that legacy finite element tools—already under development for more than thirty years by the time the F-35 program began—had ample time to mature into reliable design tools. While user interfaces and computational speed advanced significantly during that period, the underlying element-centric software architecture, rooted in the mid-1960s understanding of the finite element method, lacks the flexibility to incorporate important theoretical and algorithmic developments that occurred later and bear directly on the reliability of strength predictions.
The Root Causes of Stagnation
How has it come to pass that widely used engineering software systems are decades out of date? — The answer lies in a broad governance gap. To understand this, we must examine both the developers’ and the users’ perspectives.
Clearly, it is the professional responsibility of software developers to provide their customers with the best available technology. The developers of legacy finite element software, members of the engineering community, have historically relied on engineering research guided by pre-scientific approaches. They have failed to recognize the relevance of academic research that has produced important results—largely because those results are expressed in the language of applied mathematics, which is virtually inaccessible to most engineers. Another, even larger problem is that the software architecture of legacy finite element codes was not designed to support these later developments. Overhauling legacy codes already embedded in engineering workflows was ultimately seen as an impossible mission.
A big part of the problem was that regulators, government acquisition specialists, and industry users all approached numerical simulation software the wrong way. They took whatever was commercially available and assumed it was good enough to support key design decisions. Frank Kendall’s remarks should be understood in this light. But despite the hindsight he pointed out, not much has changed in the 14 years since. At this point, it is hard not to see this as a widespread operational process failure.
Roadmap to Progress
The reliability and hence usefulness of numerical simulation will greatly increase when software tools incorporating advances in the science of finite element analysis become widely available to the engineering community.
This is a large undertaking that will require a shift from the current element-centric view of numerical simulation to a model-centric approach, along with a software architecture capable of supporting the construction of hierarchical sequences of finite element spaces and the hierarchical treatment of model-form errors [4]. These capabilities are essential prerequisites for verification and validation, which legacy finite element software does not support, and are also necessary for integrating numerical simulation with explainable artificial intelligence (XAI) [5]. The following outlines practical next steps toward achieving this goal.
- Acknowledge the limitations of legacy finite element software and understand these tools primarily as structural modeling tools. This does not mean they cannot be properly applied to solve strength problems; however, doing so requires expertise to identify admissible elements and appropriate input data. Estimating errors in the quantities of interest is generally difficult, expensive, and time-consuming, and is therefore typically avoided in industrial applications.
- Stakeholders concerned with reliable predictive performance—such as regulatory agencies, government acquisition specialists, and aircraft companies—should establish standards for the acceptability of information generated by numerical simulations. These standards should require that such simulations produce decision-grade, evidence-supported information. Note that compliance with the standards ASME V&V 40 and/or NASA‑STD‑7009B is not sufficient to establish decision‑grade reliability. These standards are primarily process- and credibility-based and do not ensure that specific model predictions are sufficiently reliable for their intended use.
- Organizations that rely on information generated through numerical simulation should implement effective simulation governance [5]. The goal of simulation governance is to ensure that the predicted quantities of interest are as reliable as those obtained from physical experiments. From a management perspective, this aligns with the objective of maximizing the return on investment in numerical simulation projects.
Takeaways
- Finite element modeling asks: What mesh and elements should I use? — Simulation science asks: How reliable is the predicted quantity of interest, and how do we know?
- There is a very large unrealized potential in numerical simulation.
- The mathematical foundations of finite element analysis have been mature for decades, but legacy finite element software has not made them accessible. Consequently, engineering practice has not kept pace. Legacy tools remain effective for structural modeling tasks, but they cannot deliver decision-grade reliability in strength predictions.
- If we want simulation to support reliable engineering decisions, we must stop treating it as an intuitive modeling exercise and instead treat it as a rigorous scientific process—one that requires error estimation, verification, and evidence that the predicted quantities of interest meet the requirement for decision-grade reliability. Without this shift, simulation will continue to produce answers—but not evidence. Consequently, the reliability of the answers will remain in question.
References
[1] Kuhn, T. S. (1997). The structure of scientific revolutions (Vol. 962). University of Chicago Press.
[2] Przemieniecki, J. S. (Principal Editor) Matrix Methods in Structural Mechanics: Proceedings of the Conference Held at Wright-Patterson Air Force Base, Ohio, 26–28 October 1965, AFFDL-TR-66-80.
[3] Kendall, F. The Acquisition Implications of the DOD Strategic Guidance and the FY 2013 Budget. Center for Strategic and International Studies, Washington, DC, February 6, 2012. Transcript: https://tinyurl.com/2x8hj6c7 [Last accessed: June 18, 2026].
[4] Szabó, B. and Babuška, I. (2021). Finite Element Analysis. Method, Verification and Validation. John Wiley & Sons Inc. Hoboken, NJ.
[4] Szabó, B. (2026). From Legacy Finite Element Modeling to Explainable Simulation: Technical Requirements for XAI in Computational Mechanics. engrXiv. https://engrxiv.org/preprint/view/7229/11798
[5] Szabó, B. and Actis, R. (2012). Simulation governance: Technical requirements for mechanical design. Computer Methods in Applied Mechanics and Engineering, 249, pp. 158-168.
Related Blog Posts:
- A Memo from the 5th Century BC
- Obstacles to Progress
- Why Finite Element Modeling is Not Numerical Simulation?
- XAI Will Force Clear Thinking About the Nature of Mathematical Models
- The Story of the P-version in a Nutshell
- Why Worry About Singularities?
- Questions About Singularities
- A Low-Hanging Fruit: Smart Engineering Simulation Applications
- The Demarcation Problem in the Engineering Sciences
- Model Development in the Engineering Sciences
- Certification by Analysis (CbA) – Are We There Yet?
- Not All Models Are Wrong
- Digital Twins
- Digital Transformation
- Simulation Governance
- Variational Crimes
- The Kuhn Cycle in the Engineering Sciences
- Finite Element Libraries: Mixing the “What” with the “How”
- A Critique of the World Wide Failure Exercise
- Meshless Methods
- Isogeometric Analysis (IGA)
- Chaos in the Brickyard Revisited
- Why Is Solution Verification Necessary?
- Variational Crimes and Refloating the Costa Concordia
- Lessons From a Failed Model Development Project
- Where Do You Get the Courage to Sign the Blueprint?
- Great Expectations: Agentic AI in Mechanical Engineering
- The Differences Between Calibration and Tuning
- Honored in the Breach
- Remembering Ivo Babuška
- Turtle Shells and Legacy Finite Element Codes: Evolutionary Constraints in the Age of Explainable AI
- Beyond the Black Box: Explainable AI Requires Explainable Simulation
- Trustworthiness in Simulation: Credibility or Decision-grade Reliability?
Serving the Numerical Simulation community since 1989 






Leave a Reply
We appreciate your feedback!
You must be logged in to post a comment.