ARTIGO ORIGINAL
DE SIMONE, A. P.[1]
DE SIMONE, A. P. Evolution and manufacturing of finite element software: A historical and software engineering perspective. Revista Científica Multidisciplinar Núcleo do Conhecimento. Year 11, Edition 01, Vol. 02, pp. 74-84. January 2025. ISSN: 2448-0959. Available at: https://www.nucleodoconhecimento.com.br/computer-engineering/evolution-and-manufacturing, DOI: 10.32749/nucleodoconhecimento.com.br/computer-engineering/evolution-and-manufacturing
ABSTRACT
This paper presents a historical and technical analysis of the development of software based on the Finite Element Method (FEM), focusing on the manufacturing process and the evolution of software engineering practices employed since the early programs in the 1950s. The phases marking the transition from artisanal scientific programming to systematic software engineering are examined, including the evolution of development processes from the waterfall model to agile methods and continuous integration. The study highlights classic cases such as NASTRAN and SAP, and analyzes in detail the modern architecture of libraries such as deal.II, evidencing how separation of concerns, generic programming, and test automation have transformed these codes into complex and sustainable industrial products.
Keywords: Finite Element Method, Software Engineering, Development History, Scientific Software Manufacturing, Computational Simulation.
1. INTRODUCTION
The Finite Element Method (FEM) revolutionized the way engineers and scientists solve structural, thermal, and fluid analysis problems. Although its mathematical basis is widely documented, the manufacturing process of the software that implements the method is equally relevant and frequently overlooked in technical literature. Since the early decades of FEM, developers have faced not only numerical challenges but also software engineering ones: modularization, maintenance, documentation, and portability. These challenges shaped the historical trajectory of finite element software manufacturing, evolving it from monolithic and empirical codes to collaborative, open, and systematized ecosystems.
2. THE ORIGINS: ARTISANAL PROGRAMMING AND EARLY CODES (1950–1970)
The first finite element software emerged in the academic and industrial environment of the 1950s, within a context of rapid advancement in scientific computing. Researchers such as Turner et al. [1] and Clough [2] established the theoretical foundations of the method.
The creation of NASTRAN in 1968, under NASA sponsorship, represented a watershed moment. According to MacNeal [3], the project was conceived with a modular architecture composed of “executives” and “functional modules,” anticipating the modern concept of component-based software. This approach allowed for the replacement and improvement of parts of the code without rewriting the entire system, an unprecedented advance at the time and one of the first practical applications of software engineering in scientific codes.
The documentation process of NASTRAN, according to Douglas [4], was equally revolutionary. The team at Computer Sciences Corporation (CSC), in partnership with the MacNeal-Schwendler Corporation, adopted a “Type 1 documentation” model, in which the system specification was drafted and validated even before programming began. This methodology provided for continuous documentation throughout development of the so-called policy of document as you develop which ensured consistency between theory, implementation, and usage.
Two main categories of documents were created: the Mathematical Specifications (MS), containing the theoretical and mathematical development of each module, and the Functional Module Mathematical Specifications (FMMS), which detailed the algorithms, data flows, and constraints of each component. The MS fed into the Theoretical Manual (TM), while the FMMS served as the basis for the Programmer’s Manual (PM). Finally, the User’s Manual (UM) gathered input and output specifications, examples, and glossaries, deriving from various auxiliary documents.
The effort was coordinated by Frank J. Douglas, who served as the NASTRAN Documentation Manager, responsible for editorial management and compatibility among the three manuals. Internal document MS-47 defined the format and style of the documentation, including formatting guidelines, glossary, and typographic conventions. This rigor resulted in a quality standard that influenced subsequent generations of technical documentation in engineering software.
Douglas also highlights that the absence of professional technical writers was a challenge: the engineers and programmers themselves were the authors of the manuals. The process involved multiple revisions, exchanges between teams from CSC, MSC, and Bell Aerospace, and biweekly reviews conducted by the NASA team at Goddard Space Flight Center. Even with time and resource limitations, the final documentation of NASTRAN became a benchmark of excellence in software engineering and scientific documentation.
However, it was with the development of SAP (Structural Analysis Program) by Wilson [5] that software engineering applied to FEM gained more defined contours. Wilson conceived SAP under a pragmatic philosophy, arguing that the development of an effective program required the simultaneous mastery of three disciplines: structural mechanics, numerical analysis, and computer programming.
Unlike previous codes that were rigid, SAP was designed with a modular architecture to allow for the simple insertion of new finite elements, as Wilson believed that any structural analysis software would become obsolete in a few years due to advances in hardware and numerical methods. For this reason, he argued that massive investment in a single monolithic program was risky; the software’s longevity would depend on its ability to be small, machine-independent (coded in standard FORTRAN IV), and easily modifiable.
From a system architecture perspective, SAP innovated by implementing dynamic storage allocation at runtime. The program was structured in four sequential phases (Data Input, Stiffness Formation, Equation Solution, and Stress Evaluation) and used an equation solver (USOL) that operated in blocks, allowing systems with a large number of joints to be solved even with the limited memory of computers at the time. Interestingly, the maturity of Wilson’s software engineering was also reflected in his transparency regarding the tool’s limitations. The author stated that the name “SAP” (slang for “fool” or “naive”) was deliberately chosen to remind users that the program, like any computer code, “lacked intelligence,” and that the responsibility for the correct idealization of the structure and the results lay entirely with the engineer.
3. THE STRUCTURED ERA: STANDARDIZATION AND DOCUMENTATION (1970–1990)
With the increasing complexity of problems and the diffusion of minicomputers, the 1970s witnessed the beginning of structured software engineering applied to scientific codes.
The software ANSYS, developed by Swanson Analysis Systems, exemplifies the maturation of the software manufacturing process in this era. According to Ketelaar [6], ANSYS was conceived not just as a solver, but as an integrated package where graphics, pre-processing (mesh generation), and post-processing coexisted in a single environment. This integration represented a significant usability advance over codes that required manual manipulation of text files for data input.
From a software architecture perspective, one of the most striking innovations in the manufacturing of ANSYS was the implementation of the direct Wave-Front (or frontal) solution method. While other codes were limited by the bandwidth of the stiffness matrix, the ANSYS solver imposed no rigid limits on bandwidth; the resolution capacity depended only on the memory available for the given problem, allowing for the analysis of much larger and more complex structures.
The engineering of ANSYS also stood out for its comprehensive element library, containing more than seventy distinct elements as early as the 1980s, capable of simulating linear and non-linear behaviors, including plasticity (based on the von Mises yield function) and large deflections. Furthermore, the software was a pioneer in the multiphysics approach, allowing the same code to solve structural, heat transfer, and electromagnetic problems using a unified data structure.
The manufacturing process of these systems, therefore, began to reflect the waterfall lifecycle model. Each version went through rigorous specification and validation phases. Although still centralized, software such as ANSYS and ABAQUS [7] already displayed characteristics of a robust industrial product: extensive user manuals, quality control, technical support, and machine independence (being written in standard FORTRAN to run on various mainframes and minicomputers).
During this phase, practices of scientific documentation and numerical verification were also consolidated. Zienkiewicz [8] highlights that the validation of results, previously empirical, became an integral part of the development cycle, integrating computational tests with laboratory experiments.
4. THE TRANSITION TO SCIENTIFIC SOFTWARE ENGINEERING (1990–2010)
With the advent of Object-Oriented Programming (OOP) and C++, the manufacturing of scientific software underwent a paradigm shift. The focus shifted from rigid procedural codes to flexible and reusable libraries capable of supporting the growing complexity of multiphysics and adaptive simulations.
A paradigmatic example of this new engineering is the deal.II library [9]. Started in 1997 to overcome the maintainability limitations of previous codes, deal.II was architected not as a closed solver, but as a generalist “toolbox.” Its manufacturing introduced advanced software engineering practices that contrast with previous generations:
- Separation of Concerns (SoC): Unlike older codes where the mesh often contained solution data and node numbering, deal.II strictly decoupled geometry (Triangulation class), finite element spaces (FiniteElement class), and degree of freedom management (DoFHandler class). This allowed for the arbitrary combination of different meshes and physics without the need to rewrite the software core, facilitating code maintenance and extension.
- Generic Programming and Templates: The extensive use of templates in C++ allowed for spatial dimension independence. In deal.II, the dimension is a template parameter (e.g., Triangulation<dim>), meaning the same source code can be compiled for 1D, 2D, or 3D. This profoundly impacted the development process, allowing programmers to develop and debug algorithms in 2D (where execution is fast) and compile the final version in 3D for production with mathematical consistency guarantees, eliminating code duplication common in legacy software.
- Optimization Patterns (FEValues): To mitigate the computational cost of excessive virtual calls, common in fine-grained OOP, the FEValues design pattern was introduced. This abstraction acts as an intelligent cache, calculating and storing shape function values, gradients, and mappings at quadrature points only when explicitly requested. This ensured the necessary efficiency for highperformance codes without sacrificing encapsulation and modularity.
- Quality and Automated Testing: deal.II institutionalized industrial quality control in the academic environment. The manufacturing process included thousands of safety assertions (defensive programming) active during development for immediate detection of logical errors, in addition to an extensive battery of regression tests executed daily. This practice of Continuous Integration (CI) ensured that the rapid evolution of the code did not introduce errors into pre-existing functionalities.
This approach marked the transition from programming as an individual and artisanal activity to collaborative scientific software engineering, where documentation, modular architecture, and automated tests are as vital as the numerical algorithms employed.
5. THE CONTEMPORARY ERA: AGILE PROCESSES AND CONTINUOUS INTEGRATION (2010–PRESENT)
In recent years, the manufacturing of finite element software has incorporated practices from the information technology industry, such as agile methodologies, Continuous Integration (CI) and Continuous Delivery (CD).
Modern projects use distributed control platforms (Git, GitHub, GitLab) and automated build and test pipelines. In the case of FEniCS, the complexity of managing multiple external dependencies (such as PETSc, MPI, and SLEPc) drove the development of automated installation tools based on HashDist and binary distribution via Docker containers, aligning scientific software production with modern DevOps practices. Furthermore, quality assurance is reinforced by the use of automated testing frameworks such as pytest.
Modularity reaches a new level with the use of external libraries for linear algebra and hardware abstraction. The manufacturing process has come to include:
- Scientific specification and numerical requirements;
- Modular design and design patterns;
- Component-oriented implementation (e.g., separation between mesh generation in the mshr component and solution in DOLFIN);
- Unit and regression tests;
- Continuous integration and semantic versioning
- Distribution via containers (Docker).
The conjunction between numerical performance and software engineering becomes the core of project sustainability.
6. CONCLUSION
The historical analysis presented here demonstrates that the evolution of finite element software transcends the mere improvement of numerical algorithms; it mirrors the maturation of Software Engineering itself. The transition from the artisanal development of the 1950s to contemporary Continuous Integration ecosystems reveals that the longevity of a scientific code lies not only in the precision of its results but in the robustness of its manufacturing processes.
The case studies discussed evidence of clear patterns of success. While NASTRAN and SAP pioneered modularization and resource management in an era of hardware limitations, the modern era, exemplified by the deal.II library, proved that architectural flexibility obtained through Object-Oriented Programming and the intensive use of templates for dimension independence is fundamental for extensibility. The strict separation of concerns (geometry, topology, and physics), a crucial innovation over the monolithic codes of the past, allowed modern software to operate as true generic “toolboxes,” adaptable to multiphysics problems unforeseen by their original creators.
In short, the manufacturing of modern finite element software has ceased to be an auxiliary task of computational mechanics research to become an autonomous engineering discipline. For the future, the guarantee of scientific reproducibility and the ability to explore new hardware architectures will depend on the continuous fusion of applied mathematics and best software engineering practices, consolidating the code not merely as a tool, but as a durable and auditable scientific artifact.
REFERENCES
[1] TURNER, M. J.; CLOUGH, R. W.; MARTIN, H. C.; TOPP, L. J. Stiffness and deflection of complex structures. Journal of the Aeronautical Sciences, v. 23, n. 9, p. 805–823, 1956.
[2] CLOUGH, R. W. The finite element method in plane stress analysis. In: PROCEEDINGS OF THE 2ND ASCE CONFERENCE ON ELECTRONIC COMPUTATION. Pittsburgh, 1960.
[3] MACNEAL, R. H. The Nastran theoretical manual. Tech. Rep. SP-221. NASA, 1971.
[4] DOUGLAS, F. J. NASTRAN documentation from an historical viewpoint. In: NASTRAN USERS’ COLLOQUIUM, 1971, Hampton. NASTRAN: users’ experiences. Washington, DC: NASA, 1971. (NASA TM X-2378).
[5] WILSON, E. L. SAP: A General Structural Analysis Program. Berkeley: University of California, 1970.
[6] KETELAAR, C. Ansys: Engineering software with the design and analysis answers. In: NIKU-LARI, A. (Ed.). Structural Analysis Systems: Software, Hardware, Capability, Compatibility, Applications. Oxford: Pergamon Press, 1986. Vol. 1, p. 31–39.
[7] HIBBITT, H. D.; KARLSSON, B. I.; SORENSEN, E. P. ABAQUS/EPGEN: a general purpose finite element code. Providence: Hibbitt, Karlsson & Sorensen, 1984.
[8] ZIENKIEWICZ, O. C.; TAYLOR, R. L. The Finite Element Method for Solid and Structural Mechanics. 6. ed. Elsevier, 2005.
[9] BANGERTH, W.; HARTMANN, R.; KANSCHAT, G. deal.II: a general-purpose object-oriented finite element library. ACM Transactions on Mathematical Software, New York, v. 33, n. 4, art. 24, p. 1–27, Aug. 2007. Available at: https://dl.acm.org/doi/10.1145/1268776.1268779. Access at : 21 jan. 2026.
INFORMATION ABOUT THE AUTHORS
[1] Specialization in Product Engineering using the Finite Element Method (FEM). ORCID: 0009-0004-7541-6796. Currículo Lattes: http://lattes.cnpq.br/7923747032799823.
Authors’ contribution:
Arthur Pendragon de Simone: Research, writing, establishing the methodology and conclusions.
INFORMATION ABOUT THE MATERIAL
Conflict of interest:
There is no conflict of interest.
Acknowledgments:
No acknowledgements included.
Financing:
There is no funding.
Note on the use of Artificial Intelligence (AI):
The author used the Gemini 3.0 Pro Artificial Intelligence for translation, reorganization, and formatting of the text. However, all writing, content searches, article quality classification, and proposed research were carried out by the author.
Copyright and License Information:
This is an Open Access article distributed under the terms of Creative Commons Attribution License, which allows unrestricted use, distribution and reproduction in any medium, provided that the original author and source are credited.
The names and addresses provided in this magazine will be used exclusively for the services provided by this publication and will not be made available for other purposes or to third parties.
- ISSN (electronic version): 2448-0959
- Creative Commons License: This work is licensed under a Creative Commons Attribution 4.0 International License.
Publication History:
Material received: January 6, 2026.
Material approved by peers: January 7, 2026.
Edited material approved by authors: January 27, 2026.
