Contents
FAQ
Stuff About Me
SLFFEA FAQ
Updated 4/18/01
which gcc
or
which acc
and then put the path in the Makefile. For instance, when I do a "which gcc", I get:
/usr/bin/gcc
which is how my CC is currently defined.
Top SS-GUI stands for Self-Scaling GUI. If you resize the GUI window, all the text inside will rescale itself such that the text and color scale boxes maintain their proportions with the window, and it will also work the same as before. This is possible because the GUI is built on OpenGL rather than some packaged window manager. Top The P-Winston Motion Engine is about 300 lines of code written by Philip Winston which he has graciously and generously allowed me to use and modify for the GUI part of SLFFEA. The P-Winston enables you to use the mouse to rotate and translate the mesh, especially to refine rotations and translations done through hot keys or the GUI. It works like a trackball, but keeps the different types of motion separate. For example, holding down the left button and moving the mouse up and down will produce translation in Z. Moving it left and right with this same button held down will rotate it on the Z axis. The middle button controls translation in X and Y, and the right button, rotation in X and Y. While this seems more complex than a typical trackball, it has the advantage of isolating the movements for fine tuning of the position at which you want to view the object. Also, the P-Winston has much less computational overhead than a Mesa trackball. Note that you have to have the Mesh Window active to have mouse control. Top This is true for slffea-1.0, but for slffea-1.1, nodal averaging is used. Even though I feel it is more honest to assign color based upon Gauss points for each individual element, the output data files were getting much too big, and I had to switch to nodal averaging. (As an example, I had a brick output file which was 10 MB, and I reduced it to 2.6 MB by using nodal averaging) It should be noted that two elements which do not have nodal averaging are the beam and truss elements because stress, strain, moment and curvature are local to the coordinate system of each individual element. This is also true for the shell, but I explain why nodal averaging is justified in the README for this element. Top I claim no qualifications to write FEA code. Like all GNU software, you are using it at your own risk. That said, here is a bit of my academic history which you may use to judge my qualifications: Academic History Note that I'm not a PE and I have never taken the PE exam. Taking the exam requires 2 years of official work experience at an established company, which I do not have. Top I left the PhD program at UCSD feeling that University Academia was not for me. After being inspired by GNU/Linux, I wanted to contribute my engineering skills to the Free Software movement which represented an altruistic contrast to what I had just left. I sometimes say SLFFEA is my unofficial doctoral thesis, but now I believe that this project is worth 100 PhDs. Top For recent versions of GNU/Linux, you may not have to. (Mesa comes pre-installed on Slackware 7.1). All you need to do is add the following softlink: cd /usr/include/ ln -s /usr/X11R6/include/GL/ GLif it doesn't already exist. If you would rather compile using the latest release of Mesa, you can do the following. From Section 16.0.0 of my GNU/Linux Installation Guide:
16.0.0 Installing Mesa(the OpenGL graphics library):
16.1.0 For recent versions of GNU/Linux(like Slack-
ware-7.1), Mesa comes pre-installed. All you need to do is add the
following softlink:
cd /usr/include/
ln -s /usr/X11R6/include/GL/ GL
if it doesn't already exist.
There are several places where you can get Mesa. You can get it off
the web at:
http://sourceforge.net/project/showfiles.php?group_id=3
16.1.1 For recent versions of RedHat you need to add the glut libraries
from the RPMs on the installation disk(For RedHat 8.0, it is on the
3rd disk, for RedHat 9.0, it is on the 2nd disk):
cd /mnt/cdrom/RedHat/RPMS
rpm -Uhv glut-3.7-12.i386.rpm
rpm -Uhv glut-devel-3.7-12.i386.rpm
16.2.0 After getting the tarfiles, copy them to the
directory /usr/local/ and do:
tar xzvfp MesaLib*.gz
tar xzvfp MesaDemos*.gz
16.3.0 Compiling Mesa Programs
16.3.1 From the /Mesa-3.4.2/README:
To compile the library, first type 'make' alone to see the
list of system configurations currently supported. If you
see your configuration on the list, type 'make
Top Because Mesa is pretty standard on most GNU/Linux distributions, I think you are only lacking the glut libraries(and possibly some other include files) which usually aren't installed unless you install everything including development tools for Linux. I recommend that you check to see that the glut libraries are in: /usr/X11R6/liband that there is a directory: /usr/include/GLcontaining all the necessary Mesa and glut files. See the next question for more information. Sometimes, Redhat and Fedora have glut and glut development RPMs on their installation disk in the /RedHat/RPMS directories. You may have to look around to find it. For now, I will repeat what I say above:
To install the glut libraries from the RPMs on the installation disk(For RedHat 8.0, it is on the
3rd disk, for RedHat 9.0, it is on the 2nd disk):
cd /mnt/cdrom/RedHat/RPMS
rpm -Uhv glut-3.7-12.i386.rpm
rpm -Uhv glut-devel-3.7-12.i386.rpm
Top After updating to Mesa-3.2.1,(Mesa-3.0 should still work), doing an ls -l in /usr/X11R6/lib gives: -rw-r--r-- 1 root root 678504 2005-01-23 20:45 libGL.a lrwxrwxrwx 1 root root 12 2005-05-31 07:32 libGL.so -> libGL.so.1.2 lrwxrwxrwx 1 root root 12 2005-05-31 07:32 libGL.so.1 -> libGL.so.1.2 -rwxr-xr-x 1 root root 608015 2005-01-23 20:53 libGL.so.1.2 -rw-r--r-- 1 root root 659352 2005-01-23 20:45 libGLU.a lrwxrwxrwx 1 root root 13 2005-05-31 07:32 libGLU.so -> libGLU.so.1.3 lrwxrwxrwx 1 root root 13 2005-05-31 07:32 libGLU.so.1 -> libGLU.so.1.3 -rwxr-xr-x 1 root root 563990 2005-01-23 20:53 libGLU.so.1.3 -rw-r--r-- 1 root root 27902 2005-01-23 20:45 libGLw.a lrwxrwxrwx 1 root root 13 2005-05-31 07:32 libGLw.so -> libGLw.so.1.0 lrwxrwxrwx 1 root root 13 2005-05-31 07:32 libGLw.so.1 -> libGLw.so.1.0 -rwxr-xr-x 1 root root 26550 2005-01-23 20:53 libGLw.so.1.0 lrwxrwxrwx 1 root root 12 2005-05-31 07:22 libglut.so -> libglut.so.3 lrwxrwxrwx 1 root root 14 2005-05-31 07:22 libglut.so.3 -> libglut.so.3.7 -rwxr-xr-x 1 root root 215332 2003-08-20 14:24 libglut.so.3.7and doing an ls -l in /usr/include/GL gives: -r--r--r-- 1 root root 7946 2005-01-23 20:45 GLwDrawA.h -r--r--r-- 1 root root 4433 2005-01-23 20:45 GLwDrawAP.h -r--r--r-- 1 root root 2309 2005-01-23 20:45 GLwMDrawA.h -r--r--r-- 1 root root 2311 2005-01-23 20:45 GLwMDrawAP.h -r--r--r-- 1 root root 89951 2005-01-23 20:44 gl.h -r--r--r-- 1 root root 306424 2005-01-23 20:44 glext.h -r--r--r-- 1 root root 15981 2005-01-23 20:44 glu.h -r--r--r-- 1 root root 9016 2005-01-23 20:44 glx.h -r--r--r-- 1 root root 29020 2005-01-23 20:44 glxext.h -r--r--r-- 1 root root 4257 2005-01-23 20:44 glxint.h -r--r--r-- 1 root root 2453 2005-01-23 20:44 glxmd.h -r--r--r-- 1 root root 71034 2005-01-23 20:44 glxproto.h -r--r--r-- 1 root root 8878 2005-01-23 20:44 glxtokens.h -r--r--r-- 1 root root 8349 2005-01-23 20:44 osmesa.h -rw-r--r-- 1 root root 20844 1998-08-07 17:18 glut.h -rw-r--r-- 1 root root 5150 1998-08-07 17:18 glsmap.h -rw-r--r-- 1 root root 7273 1998-08-07 17:18 fglu.h -rw-r--r-- 1 root root 10152 1998-08-07 17:18 fglut.h -rw-r--r-- 1 root root 60468 1998-08-07 17:18 fgl.h Top Not yet. The main issue is to coordinate all the DOFs, so that rotation and translation are correctly put into their components in the global stiffness matrix. To do this, I can imagine storing all the element stiffnesses in a big file, along with DOF data, and calling a global stiffness assembler which puts everything together. My code is currently more static than this, where each element stiffness is immediately put into the global stiffness so no copies exist(an exception is when I use the Conjugate Gradient method, but that's another issue). This is a significant consideration. These files could get pretty big, and I currently want to prevent having to write out such data. If I ever do the multi-element code, I will try to keep this type of data in the program's memory space, if at all possible. When I first began planning SLFFEA, I made the design choice to initially keep things simple. I thought I could go back and do the multi-element code one day, when I had finished doing the other elements. Not all elements can be mixed(some non-linear elements for example), and I would have an idea of which ones could and could not be combined after I had finished all the others. It was more important at the time to come up with codes that could generate all the different element stiffness types, which could later be used in the super-element code. Top There are a few generators for specific meshes like the ball and ring composed of brick elements, or the building made up of beam elements. For more general mesh generators, try the links below, especially the fourth. Meshing Research Corner Jonathan Richard Shewchuk's triangle element mesh generator C program. Mesh Generation & Grid Generation on the Web A very extensive list of software from the same site as above GiD is a cost free(but not open source) package. Top For units, just be consistent. If using inches and lbs, then you would use psi for Young's modulus. If meters and Newtons, then Pascals. So you can use any system of units you want. Top This is a common issue with Unices. For the beam, instead of just "bm", type in: ./bmwhich means execute the code "bm" in your current directory. You can also add: export PATH=$PATH:.or export LD_LIBRARY_PATH=.in your ".bashrc" or ".bash_profile" (or whatever your Unix uses) to avoid having to type "./" before every executable. The reason this is not automatically done in Unix is for security reasons, so you may want to think about adding "." to your path. Top |
I'll add more Questions and Answers as they come. Top |
You are visitor number 
since 2/21/00