Stuff About Me
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.
- A paradigm for structures which group like variables, but isn't so
bloated that it passes quantities which aren't needed to a subroutine.
- A paradigm for variable names, file names, and array storage which
would enable a user's understanding of one element code to transfer
- A paradigm for subroutines and program structure which would enable
a user's understanding of one element code to transfer to another.
- 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.
- 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.
- Have no redundant data. Scientific and graphics data would be the
- 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
- 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.
- 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