Computational & Technology Resources
an online resource for computational,
engineering & technology publications |
|
Computational Science, Engineering & Technology Series
ISSN 1759-3158 CSETS: 5
CIVIL AND STRUCTURAL ENGINEERING COMPUTING: 2001 Edited by: B.H.V. Topping
Chapter 6
Object Oriented Programming for Structural Mechanics: A Review R.I. Mackie
Department of Civil Engineering, University of Dundee, United Kingdom R.I. Mackie, "Object Oriented Programming for Structural Mechanics: A Review", in B.H.V. Topping, (Editor), "Civil and Structural Engineering Computing: 2001", Saxe-Coburg Publications, Stirlingshire, UK, Chapter 6, pp 137-159, 2001. doi:10.4203/csets.5.6
Keywords: object-oriented programming, finite element analysis, structural analysis.
Summary
One of the most important developments in software engineering in the past decade
has been object-oriented programming. From being something of a novelty, it is now
the predominant programming paradigm, usually in the form of C++, Java or
Delphi. Fortran has for many years been the standard language for scientific
programming, but this is now beginning to change. There is increasing interest in the
use of C++ in scientific computing, and object-orientation is influencing Fortran
itself. In terms of structural engineering, the finite element method is the most
important computational technique, and over recent years there has been growing
interest in applying object-oriented methods to finite element analysis [1].
There are two broad reasons for applying object-oriented methods to finite element programming:
The complexity in finite element software arises from a number of sources, including:
The finite element method itself is naturally amenable to the object approach. All finite element models consist of nodes and elements, and much of their behaviour is similar, regardless of the particular application. For example, a stiffness matrix can be calculated for all elements. Moreover, the solution processes are similar, regardless of the element type. The paper describes how the object-oriented approach can be used to handle much of the complexity. Much of the early work focused on the development of finite element classes, this being the most obvious place to start. Paradoxically this is an area where much work still remains to be done. While class hierarchies are easy to develop for limited applications, as the range of applications increases the hierarchy can become very cumbersome. Most work so far has relied almost entirely on the inheritance mechanism. It is likely that composition and component technology will have a greater role to play in the future. A great deal of work has been done on developing matrix libraries, with many of these being template based [2]. It has been demonstrated that early concerns about poor computational performance of object-oriented algorithms are unfounded. Equally importantly from a software engineering point of view, it has proved possible to develop flexible solution libraries that can be interfaced with finite element software, or other applications. Relatively little attention has been devoted to user-interfaces, with most work on finite elements focussing on the numerical aspects. However, the work of the current author has shown how an object-oriented approach greatly facilitates the development of user-friendly software. Similarly, relatively little work has been done on linking finite element analysis with other programs. Concurrent processing is a developing area receiving much attention. While parallel processing used to require special machines, there is growing interest in using clusters of PC's or workstations [3]. This is likely to develop further as the web opens up further opportunities for distributed computing. The advantages offered by the object-oriented approach can be put into two groups:
The primary contribution of object-oriented programming to structural engineering, and finite element software in particular is to apply the benefits of software engineering to engineering software. References
purchase the full-text of this chapter (price £20)
go to the previous chapter |
|