Contents


SLFFEA HOME

SLFCFD HOME

SLFCEM HOME

GUI

Image Gallery

Download

Philosophy

Preamble

FAQ

GNU/Linux

Update

Development

Acknowledgments

Links

CFD

Periodic Table





Stuff About Me

San Le

Artwork

Email

Updates to SLFFEA

Updated 10/3/01



Here is a summary of the updates as of 10/2/01:

I fixed a bug related to the calculation of the volume of the shell element. Because volume is not involved in any of the scientific calculations, this doesn't have any effect on any results other than the volume itself. Finding volume(and area) involves numerical integration where the determinant is added up multiplied by the associate weights. My mistake was adding the 2 shear integration points to the 8 2X2X2 gauss integration points which were all that was needed. To make the fix yourself, look for and remove the lines:
/* Calculate the Volume from determinant of the Jacobian */

                *Vol=*Vol+*(det+num_int+k2);
in the ~/slffea-1.*/shell/shell/shshape.c file. BE CAREFUL to only remove the volume calculation which is contained in the loop for the 1X1 integration in the lamina which is below the lines:
/*
   calculating the dN/dx,dy,dz and dza/dx,dy,dz matrices for 1X1
   integration in lamina
*/
This fix has been made for SLFFEA-1.0 and SLFFEA-1.1 as well as for the development code which I am now calling SLFFEA-1.17 do to the changes made since 1.15. For 1.17, I have done a lot of work on the scientific codes for the triangle, tetrahedron, and wedge elements as well as wrote new subroutines to calculate the areas and volumes separately from the shape function subroutines.

Here is a summary of the updates as of 7/14/01:

I have put up the development code slffea-1.15 (It will still be called slffea-1.2 when you extract the tarfile). I had planned on waiting until it was fully slffea-1.2, but decided there were enough nice features to put this development version up. Here are the new features:
  1. Rendering improved-You can see this by looking at the main page. Now rendering retains the colors of the current analyzed quantity.
  2. Cutting planes-This is a very exciting addition to the GUI because it allows you to cut away layers of the mesh and look inside. Please use it. Press the hotkey "s" and the cutting planes will appear. Now you can use the arrow keys to move the x and y cutting planes. Also, < and > move the z cutting plane.
  3. New elements-I have added the graphics code for 3 new elements (I am still working on the science part). The new elements are:
    1. 3 node plane stress/strain triangle elements
    2. 4 node tetrahedral elements
    3. 6 node wedge elements
  4. Labeled axes-I have added numerical labeling of the hash marks on the axes.
  5. Electromagnetic Quad Element Code-NO, IT IS NOT FINISHED. And considering the lack of help, I will probably be putting it off until I finish the mechanical engineering science codes for the three new elements above.
I will officially call the code version 1.2 when I finish the science parts for the three codes above. I would recommend that you use this code now instead of slffea-1.1, just so that you can use the new features. Everything is mostly stable except for the aforementioned science parts. The EM code probably won't be finished for a long time.

Here is a summary of the updates as of 6/12/01:

Discovered very small bug in ~/slffea-1.1/truss/truss_gr/tsparam.c on lines 178, 184, 192, and 198. Change those lines from:
                min_stress_integ.xx = j;
to:
                min_stress_integ.xx = 0;
I'm not going to bother uploading everything for this bug.

Here is a summary of the updates as of 3/30/01:

For some reason, the changes for 1/16/01 disappeared from the code, so I had to re-implement them. I have no idea why this happened.

Here is a summary of the updates as of 3/18/01:

In computer programming, sometimes two wrongs make a right, at least for awhile. After updating to Mesa-3.4.1, I discovered an error related to how I calculated the normals of the faces in the graphics codes. I reversed the cross-product, which compounded with the fact that I put the light source on the negative of the z axis, produced a seemingly correct result. The canceling out of errors no longer works under Mesa-3.4.1, and so I have made the following fixes in the graphics codes. These fixes only effect the rendering.

  1. In the brick, plate, and shell elements, switch d1 and d2 in the function call for normcrossX in all the *norm_vec.c files. So change:
                    normcrossX(d2, d1, norm_temp);
    
    to:
                    normcrossX(d1, d2, norm_temp);
    
    For the quad element, change
    norm_temp[] = {0.0, 0.0, -1.0};
    
    to
    norm_temp[] = {0.0, 0.0, 1.0};
    
    in both qdmesh.c and qdrender.c
  2. In the file *post.c, change:
    GLfloat light_position[] = { 1.0, 1.0, -6.0, 0.0 };
    
    to
    GLfloat light_position[] = { 1.0, 1.0, 6.0, 0.0 };
    
  3. For some reason, the background color of the mesh window changed from light grey to purple. This may be a problem with either Mesa-3.4.1 or my graphics card, so I fixed it by changing
       glClearColor(.5, .5, .5, 1.0);
    
    to
       glClearColor(.51, .51, .51, 1.0);
    
    in the file ~/slffea-1.0/common_gr/mshcommon.c
Finally, I have modified the graphics Makefiles in slffea-1.1 and slffea-1.0 to reflect the changes in Mesa-3.4.1 as well the fact that the Mesa library now comes pre-installed on many GNU/Linux distributions. Replace:
LIB2 = -L../lib -lglut -lGLU -lGL -lm -L/usr/X11/lib \
        -L/usr/X11R6/lib -lX11 -lGL -lGLU -lXext -lXmu -lXt -lXi -lSM -lICE
with
LIB2 = -L/usr/local/lib -lglut -lGLU -lGL -lm -L/usr/X11/lib \
        -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lSM -lICE
This will enable SLFFEA to compile either with your installation of Mesa or the version which comes with your distribution. Note that the following softlink needs to exist in the directory /usr/include/:
lrwxrwxrwx   1 root     root           21 Mar 18 03:38 GL -> /usr/X11R6/include/GL/
If it doesn't exist, you can set it with:
      cd /usr/include/
      ln -s /usr/X11R6/include/GL/ GL
One problem with the above is that there may be conflicts with your distribution's pre-installed version and the one you put in /usr/local/. I have had trouble forcing SLFFEA to compile against the correct version.

Here is a summary of the updates as of 1/22/01:

Change line 201 in ~/slffea-1.1/truss/truss/femtruss.c from:
#if 1
to
#if 0
I was testing the Conjugate Gradient Solver and forgot to turn this off.

Here is a summary of the updates as of 1/17/01:

I have modified the graphics Makefiles in slffea-1.1 and slffea-1.0 to reflect the changes in Mesa-3.2.1. Replace:
LIB2 = -L../lib -lglut -lMesaGLU -lMesaGL -lm -L/usr/X11/lib \
        -L/usr/X11R6/lib -lX11 -lGL -lGLU -lXext -lXmu -lXt -lXi -lSM -lICE
with
LIB2 = -L../lib -lglut -lGLU -lGL -lm -L/usr/X11/lib \
        -L/usr/X11R6/lib -lX11 -lGL -lGLU -lXext -lXmu -lXt -lXi -lSM -lICE

Here is a summary of the updates as of 1/16/01:

And yet more bug fixes from Qi Yang:

For the brick, brick2, quad, plate, and shell element graphics codes, replace:
        free(stress_node);                
        free(strain_node);                
with
        free(mem_SDIM);                
and for the plate, also replace:
        free(curve_node);                
        free(moment_node);                
with
        free(mem_MDIM);                
I have also added the:
        free(mem_SDIM);                
and additionally for the plate:
        free(mem_MDIM);                
for the science codes of the brick, brick2, quad, plate, and shell elements.

I have also slightly improved the Conjugate Gradient solver for the elements by reducing 3 dot products to 1. It may be worth it to download everything again.

Here is a summary of the updates as of 12/24/00:

Based on the last bug fix, I went though slffea-1.0 and found the following mistakes:

On line 352,353 of ~/slffea-1.0/truss/truss_gr/tspost.c, change
                fscanf( o1, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3);
to
                fscanf( o1, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n ",dum,dum1,dum2);
and line 359,360 from:
                fscanf( o3, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n",dum,dum1,dum2,dum3);
to
                fscanf( o3, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n",dum,dum1,dum2);
On line 358,359 of ~/slffea-1.0/plate/plate/plpost.c, change
                fscanf( o1, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3);
to
                fscanf( o1, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n ",dum,dum1,dum2);
and line 365,366 from:
                fscanf( o3, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n",dum,dum1,dum2,dum3);
to
                fscanf( o3, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n",dum,dum1,dum2);
On line 364,365 of ~/slffea-1.0/beam/beam_gr/bmpost.c, change
                fscanf( o1, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3);
to
                fscanf( o1, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n ",dum,dum1,dum2);
and line 371,372 from:
                fscanf( o3, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n",dum,dum1,dum2,dum3);
to
                fscanf( o3, "%d %d %d\n ",&dum,&dum1,&dum2);
                printf( "%d %d %d\n",dum,dum1,dum2);

Here is a summary of the updates as of 12/21/00:

Once again, the reliable Qi Yang has come up with a few more bugs:

On line 383 of ~/slffea-1.1/brick/brick2/br2post.c, change
                printf( "%d %d %d %d %d %d\n ",dum,dum1,dum2,dum3,dum4);
to
                printf( "%d %d %d %d %d %d\n ",dum,dum1,dum2,dum3,dum4,dum5);
On line 371-372 of ~/slffea-1.1/beam/beam_gr/bmpost.c, change
                fscanf( o1, "%d %d %d %d %d\n ",&dum,&dum1,&dum2,&dum3,&dum4);
                printf( "%d %d %d %d %d\n ",dum,dum1,dum2,dum3,dum4);
to
                fscanf( o1, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3);
and line 378-379 from:
                fscanf( o3, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3,&dum4);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3,dum4);
to
                fscanf( o3, "%d %d %d %d\n ",&dum,&dum1,&dum2,&dum3);
                printf( "%d %d %d %d\n ",dum,dum1,dum2,dum3);
Do the exact same for bmgetnew.c except the lines are 184,185 and 191,192 respectively.

Here is a summary of the updates as of 12/15/00:

Some more modifications based on the work of Qi Yang. Again thanks to him for pointing out the following bugs:

The graphics code files *getnew.c were inconsistent in the way the function *GetNewMesh was defined. Sometimes it was an "int" and other times, a "void". I also forgot to do a "return 1" at the bottom when it was an "int". They are all now set to being "int" with a "return 1" at the bottom of the function.

Change a #define for the file ~/slffea-1.1/common_gr/control.h from:
#define IBIG                1e20
to
#define IBIG                1e7
The range of an integer data type goes only up to about 2e9 on a 32 bit OS.

I also added a few function headers I had missed to some source files. These aren't really bugs, but they should be fixed anyway. Other things Qi Yang noted, like "unreferenced variables", I am leaving in the program.

Here is a summary of the updates as of 12/13/00:

Thanks to Qi Yang for pointing out the following bugs:

On line 55 of ~/slffea-1.1/plate/plate/plwriter.c, change
        fprintf( o3, "    %4d %4d %4d %4d\n ", numel, numnp, nmode, nmat);
to
        fprintf( o3, "    %4d %4d %4d %4d\n ", numel, numnp, nmat, nmode);
and at the bottom of every fem*.c file, change
        free(eigen);
to
        if(modal_flag) free(eigen);
if you don't want to download again.

Here is a summary of the updates as of 10/27/00:

I got access to an SGI and built SLFFEA using that machine's compiler. It caught some small errors which gcc missed, and so I've done a little clean up on the code. The problems weren't significant, and the most important change is to the files *lanczos.c, *kasmbl.c, and *conj.c in all the scientific software element directories. Change:
extern lin_algebra_flag, numel_K, numel_P;
to
extern int lin_algebra_flag, numel_K, numel_P;
if you don't want to download again.

Here is a summary of the updates as of 10/24/00:

I made a small modification to the file ~/slffea-1.1/common_gr/eigenprint.c. In addition to printing out the eigenvalues, I also print out the frequency data(which is just the square root of the eigenvalues). You can make the modification yourself by changing ~/slffea-1.1/common_gr/eigenprint.c, beginning with line 200, to:
        for( i = 0; i < nmode; ++i )
        {
            if(eigen[i].val > 0)
            {
                fdum = sqrt(eigen[i].val);
                fdum2 = fdum/(2.0*pi);
                fprintf(o1, "\n mode number %4d     %16.8e    %16.8e    %16.8e",
                        i+1,eigen[i].val, fdum, fdum2);
            }
            else
            {
                fprintf(o1, "\n mode number %4d     %16.8e < 0     NOT VALID",
                        i+1,eigen[i].val);
                fprintf(o1, "           NOT VALID");
            }
        }
        printf( "\n");
Also, add on line 184:
        double fdum, fdum2;

Here is a summary of the updates as of 10/14/00:

Upon further consideration, I have decided that nodal averaging of stress, strain, moment and curvature for beams and trusses does not represent the data well because these quantities 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. You can read more about it in the READMEs located in the respective directories of the beam, truss, and shell. So for the beam and truss, data will be like it was in slffea-1.0.

I also fixed a bug in the file ~/slffea-1.1/common_gr/filecheck.c. Since you should download again anyway, I won't bother explaining the fix I made.

Here is a summary of the updates as of 10/12/00:

Version 1.1 is finally here.

You can get it at the download page. There have been major changes made to the code as well as input files. Here are the most significant:

Science Code Changes
  • Added modal analysis. Now you can see the different modes of the mesh during free vibration.
  • Added an accelerated linear algebra solver which uses the Conjugate Gradient Method. This saves a lot of memory and speeds up the solution time for very large meshes. The size of the problem you can solve has now expanded from 6,000 DOF to 240,000 DOF with only 64MB. So now, you can solve a brick problem with 80,000 nodes whereas before, you could only solve a mesh with about 2,000. And as an added plus, the Conjugate Gradient Method is highly parallelizable as you can see by the work of some students at the University of Illinois, Champaign.
  • Added mass matrix assembler that does both consistent masses as well as lumped masses. This was obviously needed for the modal analysis.
  • This isn't really new, but I'll mention it anyway. I added a thermal brick element in may.

Graphics Code Changes
  • I had already added the ability to do node, element, and material ID a few months ago. Now, you can also use the hotkey "g" to load in a new input file. So you don't have to quit the program everytime you want to look at a new mesh.

Data Changes
  • The most significant change to the data files in terms of input are that you now have to specify a number for the variable nmode, and also give data for the density of the material you are working with. The variable nmode represents how many eigenvalues you want to calculate. If you just want to solve a standard deformation problem, set nmode = 0.

    As an example, an old brick data file looks like:
    
       numel numnp nmat   
        224   512   1
    matl no., E modulus and Poisson Ratio
    0   100000000.0000   0.2700
    
    
    and the new one looks like:
    
       numel numnp nmat nmode 
        224   512   1   -5
    matl no., E modulus, Poisson Ratio, density
    0   100000000.0000   0.2700     2770.0000
    
    
    Everything is clearly labeled so hopefully, there won't be too much confusion. The reason nmode = -5 is because I usually use consistent masses when solving for eigenmodes. To use lumped masses, you can use nmode = 5(This is not recommended. You can read more about this in the file MODAL.ANALYSIS found in the directory ~/slffea-1.1.)
  • Because data files were getting too big, I now do nodal averaging of quantities such as stress and strain. The impetus came from solving a problem with 4200 elements and 5027 nodes which produced an output data file exceeding 10MB. I was able to reduce its size to 2.6 MB with nodal averaging. You are still able to see stresses and strains written out on a per element basis at either gauss points or nodes, if you want. But normally these quantities are not written out, and are not used in the graphics part of SLFFEA.
  • There is now an input data file for every element called *input which gives parameters for calculation. For instance, in the brick data directory, there is a file, "brinput", which contains the data:
    
    Error tolerance   
    1.e-13
    Maximum number of iterations
    2000
    Amount of RAM in megabytes
    64.0
    element stress read flag
    1
    element stress print flag
    0
    node or gauss stress ( 0 = node, 1 = gauss )
    1
    eigen print flag
    0
    
    
    1. Error tolerance = convergence criteria if the Conjugate Gradient Method is used.
    2. Maximum number of iterations = the maximum number of iterations if the Conjugate Gradient Method is used. This is good to specify to prevent the problem from running forever if the error tolerance never gets reached. An example of where this may happen is if you don't prescribe enough boundary conditions and there is rigid body motion. You should be aware that a positive definite system arising from a properly prescribed problem should always converge. I also write out the status of convergence as the problem gets solved using Conj. Grad., so you can see if a solution is forthcoming.
    3. Amount of RAM in megabytes = Amount of RAM your computer has.
    4. element stress read flag = If your problem has pre-stressed elements, setting the flag to 1 will make SLFFEA search for the file (filename).str where (filename) is the name of the main input data file. I don't think most people will have to deal with this. I use it for when I need to break up a non-linear calculation.
    5. element stress print flag = Print stress data on an element basis in the file (filename).str.obr.
    6. node or gauss stress = If 0, calculate stresses and strains at nodes. If 1, calculate them at gauss points.
    7. eigen print flag = print eigenvalue data such as the resulting T matrix from a Lanczos tri-diagonalization, Lanczos vectors, etc.
Go here to see the previous update page listing the modifications leading to Version 1.1.

Get San Le's Free Finite Element
Analysis at SourceForge.net. Fast, secure and Free Open Source software
downloads