Philosophy

Updated 7/20/99

SLFFEA Philosophy

Having written several FEA codes, including both the scientific and graphics parts, and worked with and taught a class using a large commercial code, there were several things I wanted to accomplish when designing SLFFEA:

Write it so that other engineers and scientists could develop, modify, and learn from it. Also provide users as much information and development tools as possible.
Optimize it for speed, efficiency, memory requirement, and robustness except where such optimization would conflict with the first law.
Come up with an FEA software paradigm which will easily accommodate every type of element, especially non-linear large deformation elements.
1. A paradigm for structures which group like variables, but isn't so bloated that it passes quantities which aren't needed to a subroutine.
2. A paradigm for variable names, file names, and array storage which would enable a user's understanding of one element code to transfer to another.
3. A paradigm for subroutines and program structure which would enable a user's understanding of one element code to transfer to another.
4. Use the word "paradigm" in a way which is appropriate to the sentence and not just as a meaningless buzz word.
Come up with a data file format which would minimize the amount of data needed for analyses and graphics.
1. This format would be such that input and output data were almost identical so that the post-processor could also act as the pre-processor.
2. Have no redundant data. Scientific and graphics data would be the same.
Write a GUI which could be used for both scientific visualization of the mathematical data as well as for examining an input mesh before analysis was done.
Build everything on GNU software development tools so that SLFFEA itself will have maximum freedom in terms of acquiring it and sharing it.
Follow the Unix Philosophy of having several different commands do one individual task rather than one giant program which handles several tasks. This means that there is one scientific executable for each element and one GUI for each element. The code is then not weighted down by what to the user may be superfluous features and will probably run much faster than the large commercial codes.
1. Break up SLFFEA into individual modules so that understanding the code and modifying it only has to be done for one element.
Take advantage of C's dynamic memory allocation.

You are visitor number