SLFFEA 1.1 Brick 2 README

                    Copyright (C) 1999 San Le

                    email:     slffea@juno.com
                    homepage:  http://www.geocities.com/Athens/2099/slffea.html


This directory contains the second linear brick code I have written.
It can handle thermal loads as well as orthotropy.  The data for it is
in the directory slffea-1.0/data/br2/.  It has a lot of features not
present in the other codes but they will be incorporated eventually.

Here are some of the additional features of the thermal brick:

1)Can prescribe heat generation loads at nodes(through the quantity
  heat_node) as well as distributed evenly over the entire
  element(through the quantity heat_el) 

2)Can prescribe equivalent heat Q which is analogous to nodal
  force

3)Can prescribe convection surfaces along with the film coefficient

4)The above will create a temperature distribution over the body
  which will effect the material according to its thermal expansion
  properties.

5)Almost all of the material properties can be prescribed according to
  the global coordinate system direction, so the material can have
  orthotropic behavior.

6)This brick can also behave as the standard linear brick found in
  ~/slffea-1.1/brick/brick/ by excluding the thermal loading and
  using the same quantities for all directions.  I have included the
  meshes "ball" and "rubber" which are basically the same problems found
  in ~/slffea-1.1/data/br/ except that their data is specified for
  this new brick.

7)There are 2 elements in this directory which are examples of a fin
  mesh where heat is dissipated by convection from fin surfaces, fin2
  and fin4.  I had hoped fin4 would illustrate the advantage of
  the Conjugate Gradient Method over LU decomposition in terms of
  speed for meshes having more than 750 nodes, but unfortunately,
  the global stiffness of this mesh may have a bad condition
  ratio, i.e. (largest eigenvalue)/(smallest eigenvalue) = very big
  (See Golub, Gene H., Matrix Computations, page 521)
  I think that meshes which have a big area/volume ratio are
  ill-conditioned in general since I had debugged the problem on
  a bulky solid mesh, and Conjugate Gradient greatly out-performed
  LU decomposition(See below).  Unfortunately, due to circumstances
  beyond my control, I am unable to include these meshes.

	7a) There is a mesh generator for these fin meshes called
            meshfin.c located in ~/slffea-1.1/brick/brick2.
        7b) There also is a file called fin.in which contains
            the parameters needed by the meshfin.c to create a
            particular fin mesh.
	7c) meshfin.c generates a file called fins or fins.th
            depending on whether you want a brick mesh or a
            brick 2 mesh respectively.

This brick also has many features which will be incorporated into
the other elements:

1)For very large problems, the Conjugate Gradient method is used.
  Because it is an iterative method, the storage requirements
  go down by a significant amount.  With 64MB, you could probably
  only solve a 2000 node brick problem(6000 DOF) using LU decomp.. 
  But with the Conjugate Gradient Method, it should be possible to solve
  an 80,000 node, 240,000 DOF, brick problem (It should be noted that
  for an 80,000 node brick mesh, it would be advisable to have more
  than 64MB of RAM.  I make optimizations which greatly speed up
  the calculation, but they do require memory).  Conj. Grad. also has
  the advantage that it is faster than LU decomposition with skyline.
  For example, it took 30 minutes on a 350 MHz Pentium II for a 5,000 node
  brick problem using LU decomposition, but only 4 minutes on a 233 MHz
  Pentium II for this same problem using the Conjugate Gradient solver.
  And the RAM usage was only 26 MB, whereas the skyline took 190 MB.
  
2)Stresses and strains are extrapolated to the nodes and then averaged
  over the nodes.  Stress and strain data are the largest part of the
  output results file.  I had to make this change when the problems I
  was solving had results that were 10MB in size.  The only way to
  cut it down was to store stresses and strains only at the nodes.

3)There is a file called "brinput" which allows you to control some
  parameters such as the amount of RAM you have on your machine,
  the error tolerance, and whether you want to print the stresses/strains
  at node points per element before averaging into a file *.str.obr.
  You also can have pre-stress elements by setting the "Gauss point
  stress read flag" to 1.

4)A file called *.con is generated which contain only the surface
  elements of the mesh.  "br2post" uses this file to speed up the
  graphics by excluding the drawing of internal elements.  Without
  this file, all elements whether external or internal will be
  drawn.
 

This element was debugged against ANSYS.  The results for displacement
and temperature compared favorably, but the stress and stain data were
sometimes very different.  I have made a critical examination of the
discrepancies and feel that the problem exists in ANSYS, but i cannot
be sure.  It's too bad they don't open up their sources.  But I did
use their technical documentation to implement this element, and I
congratulate them on writing some of the best I have ever seen.


This README is contained both in ~/slffea-1.1/brick/brick2
and ~/slffea-1.1/data/br2.

                             References
                             ----------

Golub, Gene H., Matrix Computations, 3rd. Ed., The John Hopkins University
        Press, Baltimore, 1996.

Kohneke, Peter, *ANSYS User's Manual for Revision 5.0, Vol IV Theory, Swanson
        Analysis Systems Inc., 1992.

* ANSYS is a registered trademark of Swanson Analysis Systems, Inc.