The finite element method (FEM) is one of the most popular computational methods in engineering. FEM is used extensively in industries and academia as a production and research tool. There are many text books, monographs, journal articles devoted to FEM. FEM is a relatively mature method and has a long history dating back to the early 1950s. The following describes one view of how alternative finite element software could be developed and technologies available based upon my recent research where PFEM [Zhang, 1999; Zhang et. al, 2000] , a fledgling experimental Python-based finite element program, is one such product.
The discussions below are meant to be brief. We first describe a simplistic classification of the types of existing finite element software and comment on their relative strengths and weaknesses. We then discuss various software technologies that might be useful in developing robust, and possibly next generation, finite element programs including languages, procedure-oriented, object-oriented, platform dependence, scripting and programming languages, network enabled languages, design patterns etc. We then describe the visions and the directions that I would like to go to have the visions realized in some way. Comments, suggestions, collaborations are most welcome.
Many finite element programs (FEPs) exist, whether commercial, public domain or in-house. They can be classified approximately into two categories in terms of functionality: general purpose and special purpose. Most of the commercial software are general purpose in nature, although usually with different emphases. For example, ABAQUS is a general purpose finite element program but with an emphasis in (non-linear) solid mechanics with limited capability in heat transfer and simple fluid flow. FIDAP is a general fluid mechanics finite element program. Non-general purpose finite element programs are often developed in universities to solve specific problems and passing down from different generations of (graduate) students. Some of these programs also appear in finite element text books.
The following are my opinions on the various aspects of finite element software which include discussions on comparisons of languages and other software technologies. These are not meant to degrade or praise a particular technology but conclusions drawn from years of experiences in developing finite element and other software.
General purpose FEPs can usually solve a large number of problems with a reasonable amount of effort on the users' part. New features are constantly added to reflect mature computational techniques. Validation, examples of the program are also usually provided. Many general purpose FEPs also provide interfaces such that users can extend the capabilities of these programs. For example, ABAQUS [HKS, 1998] provides many user interfaces such as user materials subroutines, user elements, user constraints. In addition, commercial support is usually available which could be important for projects to meet deadlines.
However, general purpose finite element programs could be costly which may present a problem for small engineering firms or academic researchers. They can also be inefficient as they may not be able to optimize for a specific class of problems that a user wants. The inclusion of various interfaces such as user subroutines is nice but could be limited as one does not have access to all of the interfaces in the program. This could present a problem for research projects which often need to develop new methods and concepts that are not compatible with a general purpose finite element program. As the source of the program is almost certainly not available, it is difficult for a user to trace any bugs that may be present in the program. One should recall that, by definition, all software have bugs despite the best intention and quality assurance. In addition, different finite element programs usually don't inter-operate in a transparent manner despite the existence of various translators and the existence of neutral files. Interoperability is usually not desirable as each vendor would like to corner the market using a proprietary format. Finite element programs can solve a large number of engineering and sometimes scientific problems. Consequently, a general purpose FEP is usually complicated requiring many man-years to develop. This may prevent them in utilizing the latest and more efficient technology.
Special purpose programs are usually written in-house or by generation of graduate students in academia. These programs have the advantage that source code is available to create and add features for the project at hand. Optimizations can readily be implemented if desired. However, it can take a long time to develop the program as many features, or even some basic ingredients, need to be developed from scratch. Engineering researchers and graduate students are usually not versed in leading technology in software development and, even with the best intention, could develop code that is hard to understand, maintain, modify and extend. The validity of the code could also be compromised due to a lack of a testing framework.
We next discuss briefly the software technologies that may be helpful in developing better FEPs. For small-size or write-once programs, the following discussions may not be as important as extensibility, maintainability etc. are not design goals. However, even for those programs, one may find that it would be desirable to re-use the code or extend it after the initial project was completed.
The dominant language used in established, long-standing FEPs is FORTRAN, a procedural language. The language is relatively easy to master and is very efficient. The drawback is that, despite recent efforts to make FORTRAN look like object-oriented (actually more object-based), developing large-scale good quality software using FORTRAN is still difficult.
C, another procedural language has become popular due to its use in many system software. C is slightly better than FORTRAN as more tools are available and it can be slightly more modular in design than FORTRAN (e.g., separation of interface with implementation by using header files .h and implementation files .c). C is, however, a more difficult language to learn than FORTRAN mainly due to the need to explicitly manipulate pointers which is the number one cause of memory leak and associated problems.
C++, a hybrid procedural and object-oriented language, is relatively new with ANSI C++ standards formulated only in recent years. The advantage of C++ is that one can implement the concept of object-orientation - designed to solve very complicated problems such as the FEM and there are many tools readily available. However, C++ is built on top of C and hence carries all of its disadvantages if one is not careful. The language, although has object-orientation, is very complicated with many gotchas. The proliferation of C++ books to overcome these gotchas is a good testimony of the disadvantage of C++.
Java is an object-oriented, interpreted language. One can consider it as an improved C++ as it no longer has pointers. However, Java, due to its interpreted nature, is usually slow for scientific use despite the best compiler technology to date. In addition, although publicly available, Java is proprietary in nature with an international standard not looming in the near future. Also, one should keep in mind that Java was originally developed for embedded systems and was not meant to be a general purpose programming language. Java is touted as a cross platform language - write once and run everywhere. In reality, if performance is important, one often needs to use JNI (Java Native Interface) which is still platform dependent.
Python is an object-oriented, interpreted language. Similar to Java, it generates bytecodes. Python, unlike Java, is a very high level language. In this respect, FORTRAN, C, Java all belong to the category of high level languages. Python is used mostly as an scripting language but can also be used as a programming language. The most popular scripting language today is perhaps Perl. One major difference between Python and Perl is that the former is object-oriented from design whereas the latter is object-orientation as an add on (similar to C++). Perl has a syntax that is closer to system program languages such as various unix utility languages (shell, awk, sed etc.) and not well-suited for scientific software development. TCL is an older scripting language with an awkward syntax also not suitable for scientific software development.
Python is object-oriented, has an elegant syntax and allows fast prototyping. In addition:
Modular design of a software, using subroutines or procedures, is a right step towards good software. Object-orientation, through inheritance, encapsulation, metamorphism etc. is another good step toward the goal of managing complicated software. Like machine parts in engineering, using a group of objects that perform a well-defined task, a component, is another level up. Various components work towards a common goal is then called a framework. All these technologies aim at establishing interfaces at various levels. It is said that well-designed interfaces are the most valuable assets of a software. The COM technology from Microsoft is an example of component.
Component technology can also be deployed across the network. One cross-platform industry standard in network component technology is CORBA which is also object oriented. CORBA is similar to COM++, a proprietary technology from Microsoft. CORBA, by employing an interface language (IDL) that is language and platform neutral, is attractive.
Reuse-ability of code, if available, can obviously save much time in the development of code. On the other hand, a good design in software, similar to its counterpart in engineering, usually comes about after an iterative process. If one can abstract designs that share a common functionality, then one can fashion a design pattern Gamma et. al, 1995] out a class of designs. Design patterns then represent the reuse of software design.
Pfem is an open source software which carries certain advantages. From users' point of view, one can modify and extend the software if needed. By owning the source of the software, the future of the software belongs to the users. From the developer's point of view, the code can be subjected to outside scrutiny and achieve a certain level of peer review and quality control with suggestions for improvement.
The primary users I have in mind are researchers and/or graduate students. Obviously, if the program should become more functional, other people may find it useful in the long run as well. Most open-source software start scratching the itch of the developers and this is indeed my case: the desire to have a finite element program that is flexible, customizable, flexible and built with sound modern software technologies. Developing Pfem is not meant to be in competition eventually with commercial FEPs as those take many man-years to accomplish and serve a different audience.
FEM is a very powerful method which also means that it can handle many diverse applications. Tremendous amount of development effort goes into a FEP. Consequently, I do not expect Pfem to have lots of functionality in the beginning. From discipline point of view, I envision continuum solid mechanics (elasticity, plasticity) and heat transfer to be developed for Pfem. Features will be added when the need arises. Initially, a limited set of the ABAQUS input data format will be adopted. Output format will initially be in AVS UCD (unstructured cell data) format.
The program will be python-centric in that the interface will use the Python language. C or C++ (the latter is preferred) will be used whenever efficiency is important. To wrap C or C++ code into pfem, software tool such as SWIG can be used.
It is envisioned that CORBA [OMG] , with Python binding, will be used to enable Pfem to run over the network. Using IDL, then pfem can communicate with clients and servers written in other languages as well. (Also see Wang, W., 1997 ).
It is envisioned that, by wrapping up MPI or similar protocols using Python, one can also parallelize the code to run on Massively Parallel Processor computers. One can perhaps use a similar interface as Sandia's ISIS++ and FEI.
One major goal is in a sound object-oriented design (OOD) of the code in the form of a set of good interfaces (at various levels from method, to class, components and framework). Python really shines in the rapid turn around of OOD. Design patterns will be employed whenever applicable.
Unit tests will be conducted at all levels - from modules to boundary value problems. Symbolic tools, such as Mathematica, will also be used for validation. Pyunit - Python unit testing - will be employed as a unified testing framework.
Documentation will include the following:
I'd like to thank former graduate students, Wenping Wang, Chen Hao, Xianggang Zhang in developing part of the code; Professor Doug Goering of UAF for his contribution in the expertise of heat transfer; The Arctic Regions Supercomputing Center (ARSC) for computing resources.