Updates to SLFFEA

Updated 1/26/10

Here is a summary of the updates as of 4/16/12:

I have some of my art in the Bridges Organization's 2012 Conference .

Here is a summary of the updates as of 11/16/11:

My CFD paper memtioned below is now part of an issue. It is in the 20th December, 2011 issue which can be referenced as Int. J. Numer. Meth. Fluids 2011; 67:1470-1499., or completely, International Journal for Numerical Methods in Fluids, Volume 67, Issue 11, Pages 1341-1768.

Here is a summary of the updates as of 6/10/11:

I wrote a paper combining math and my art which I put on arXiv. The paper is titled, The Art of Space Filling in Penrose Tilings and Fractals . I submitted it to a math journal as well, but since it got covered by some Tech blogs like www.newscientist.com , www.technologyreview.com , and www.physorg.com , I may have exceeded the amount of pre-publishing that journals allow beyond pre-prints.

Here is a summary of the updates as of 10/11/10:

I got my first paper published. The paper is titled, Re-examining the QUICKEST algorithm for two-dimensional incompressible fluids , pubished in the journal, International Journal for Numerical Methods in Fluids .

It is based on my fluid dynamics code, SLFCFD.

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

I fixed "meshtensile.c" which is the mesh generatior for the tensile test. The way I had added nodes to have the indentation resulted in many unconnected nodes. Although it was still possible to do the calculation, the unconnected nodes had undefined displacements. While it was possible to fix all these nodes, I decided to do a major rewrite and you can see the details of the changes in the files "meshtensile.c" and "meshtensile.c.old". This file has also been replaced in SLFFEA 1.4.

Here is a summary of the updates as of 1/26/10:

Created a new project SLFCEM, which does finite element analysis for Computational Electromagnetics. You can see it at:

SLFCEM HOME

Here is a summary of the updates as of 11/26/09:

I made a small change to the shape functions of the triangle elements. This should have no effect on the results for the triangle or 3 node plate elements which use this code. I only noticed it when I began working on the electromagnetic codes, where the shape functions at the node points matter.

So for the triangle element located in:

~/slffea-1.*/tri/tri/

near line 65 of "trshape.c", change:

/* Set ra, sa, ta for shl_node calculation */

                *(ra) = 1.0;     *(sa) = 0.0;
                *(ra + 1) = 0.0; *(sa + 1) = 1.0;
                *(ra + 2) = 0.0; *(sa + 2) = 0.0;

to:

/* Set ra, sa, ta for shl_node calculation */

                *(ra) = 0.0;     *(sa) = 0.0;
                *(ra + 1) = 1.0; *(sa + 1) = 0.0;
                *(ra + 2) = 0.0; *(sa + 2) = 1.0;

Strangely, when I implemented the 3 or 6 node shell, I used the above values for "ra" and "sa".

Here is a summary of the updates as of 11/2/09:

I found 2 significant bugs in the main "fem*.c" codes. The first pretains to how the eigenvectors were assigned to the displacements and must be changed for slffea-1.1 to slffea-1.5. The second applies only to the quad and wedge codes and is for the argument list of the *Kassemble functions in "femqd.c" and "femwe.c". These must be changed for slffea-1.2 to slffea-1.5.

For the first change, for the main 9 codes "fem*.c" of beam, brick, plate, quad, shell, tetra, tri, truss, and wedge, below the comment lines:

/* Write out the eigenmodes to a (name).mod-x.obr file */

change:

*(U + i) = *(ritz + num_eigen*(*(id + i))+eigen[j].index);

*(U + i) = *(ritz + num_eigen*(*(id + i)) + j);

The former line re-orders the eigenvectors to match the re-ordering of the eigenvalues from smallest to largest. But this has already been done for the variable "ritz" in the function *lanczos.c". Because in most instances, the ordering was already correct, and there was no change. This is why the bug went unnoticed for so long.

For the next bug, go to the quad code located in:

   ~/slffea-1.5/quad/quad/

At the beginning of the file "femqd.c", near line 46, change:

int qdKassemble(double *, int *, double *, int *, double *, int *, int *,
        double *, int *, double *, MATL *, double *, STRAIN *, SDIM *, STRESS *,
        SDIM *, double *, double *);

int qdKassemble(double *, int *, double *, int *, double *, int *, int *,
        double *, int *, double *, MATL *, double *, STRAIN *, SDIM *, STRESS *,
        SDIM *, double *);

and for everywhere else you see "qdKassemble", remove the last variable "Arean" from the argument list. Do the same for the wedge element located in:

   ~/slffea-1.5/wedge/wedge/

on line 50 of "femwe.c". Change:

int weKassemble(double *, int *, int *, double *, int *, int *, double *,
        int *, int *, double *, int *, MATL *, double *, STRAIN *, SDIM *,
        STRESS *, SDIM *, double *, double *);

int weKassemble(double *, int *, int *, double *, int *, int *, double *,
        int *, int *, double *, int *, MATL *, double *, STRAIN *, SDIM *,
        STRESS *, SDIM *, double *);

and for everywhere else you see "weKassemble", remove the last variable "Voln" from the argument list.

For slffea-1.5, make the same changes as for "femqd.c" for the non-linear quad element file "femnqd.c" located in:

   ~/slffea-1.5/quad/quad_nl/

Since slffea-1.2, I have generally moved the calculation of areas and volumes outside of the "*Kassemble" routines and into their own functions. The exception is when their calculation is used for integrating the element stiffness matrix. I have re-uploaded the tarfiles for slffea-1.2 to slffea-1.5 reflecting this change.

Here is a summary of the updates as of 12/31/08:

Version 1.5 is finally here.

You can get it at the download page. There are major additions in terms of adding non-linear large deformation elements. These new elements are based on the work I did with the brick element. Here is a summary:

Science Code Changes

Expanded the double curved shell to handle triangle elements. The 4 node shell element can now handle 3 nodes. One problem though is the execssive stiffness I encountered with other triangle elements. The 3 node version should therefore be used only to get qualatative results. The data for a 3 node element is essentially the same as a 4 node element except that the element connectivity listing 3 nodes.
Added several non-linear(large deformation) codes and cleaned up the brick and truss non-linear codes. So now it is possible to use the conjugate gradient method as well as dynamic relaxation. The following elements now have non-linear counterparts.
As with most non-linear FEA software, these calculations require a little art in the selection of parameters which will keep the program stable as it iterates toward the solution. Determination of when convergence is reached as well as the choice of time step and damping so that the calculation is stable are considerations for which users will have to carefully decide.
I have changed the format of the non-linear input file files so that the parameters are better labeled as well as some additional features. The input file looks like:
```
dynamic relaxation(DR) or conjugate gradient(CG) method ( 0 = CG, 1 = DR )
1
number of iterations for DR or CG
20000
time step for DR
1.0
damping constant for DR
.02088
stress calculation for CG (Lagrangian = 0, stress updating = 1)
1
```
Most of the above should be clear, except for the "stress calculation for CG" which tells whether the stress should be calculated based on "stress updating" or whether calculated at the end using the final displacements. I compared the results for both with dynamic relaxation which only uses stress updating and neither method matched more than another.

Graphics Code Changes

The graphics codes for the shell has been modified to display the 3 node elements.

I have also added a few new mesh gererators which will also be included in SLFMESH-1.5. They generate meshes for a brick hose element and wedge loop and spring elements.

Go here to see the previous update page listing the modifications leading to Version 1.5.

Go here to see the previous update page listing the modifications leading to Version 1.4.

Go here to see the previous update page listing the modifications leading to Version 1.3.

Go here to see the previous update page listing the modifications leading to Version 1.2.

Go here to see the previous update page listing the modifications leading to Version 1.1.