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:
- Rendering improved-You can see this by looking at the
main
page. Now
rendering retains the colors of the current analyzed quantity.
- 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.
- New elements-I have added the graphics code for 3 new elements
(I am still working on the science part). The new elements are:
- 3 node plane stress/strain triangle elements
- 4 node tetrahedral elements
- 6 node wedge elements
- Labeled axes-I have added numerical labeling of the hash marks
on the axes.
- 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.
- 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
- 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 };
- 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
- Error tolerance = convergence criteria if the Conjugate Gradient
Method is used.
- 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.
- Amount of RAM in megabytes = Amount of RAM your computer has.
- 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.
- element stress print flag = Print stress data on an element basis
in the file (filename).str.obr.
- node or gauss stress = If 0, calculate stresses and strains at nodes.
If 1, calculate them at gauss points.
- 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.
|
|