BGA example home page
Next BGA page
Ball Grid Array Example bga-1 for the
[Click for the bga-1.fe datafile in a second window.]
This is the simplest model of the BGA joint. The pads are fixed, parallel,
concentric disks at a fixed separation. The solder completely wets both
pads. The only energy is the surface tension of the solder, which is
taken to be the default value of 1. There is no gravity.
|Conceptual model of initial shape.
||Labelling of datafile vertices and edges.
|Triangulation upon loading.
The starting shape is a hexagonal prism. Starting shapes should be
as simple as possible while still capturing the essential geometry.
The pads will become more circular as the surface is refined.
The drawing shows the labelling of the initial vertices and edges.
vertices 1 - 6 are on the lower pad, and vertices 7 - 12 are on the upper
pad. The edge labels are displaced toward the heads of the edges.
The top pad (face 8) is set to the color green, the lower pad
(face 7, not seen) is red, and the solder surface (faces 1-6) is white (which shows as gray
due to the lighting).
- The initial faces do not need to be triangles, nor planar. But they
should be reasonably convex so they triangulate nicely when loaded in
- All the initial vertices, edges, and faces on the upper and lower pads
are declared FIXED in the datafile. The pad vertices are fixed because
we are assuming the solder completely wets the pads. The edges and faces
are fixed so the vertices resulting from refining them are fixed.
The circularity of the pads is implemented by means of constraint 1,
x^2 + y^2 = radius^2,
which is applied to the vertices and edges around the pad rims.
Without this constraint, the pads would remain hexagonal as the surface
was refined. With this constraint, new vertices created by refining the
rim edges are forced out to the circle. It is perfectly proper to have
fixed vertices also on constraints, since a constraint only controls
motion in one direction.
The height of the upper pad in the datafile is defined as a macro "height".
It doesn't much matter in this case whether a macro or a parameter is used,
but since changing a "height" parameter at runtime would have no effect
in this datafile, I have chosen to use a macro. The appearance of
"height" in the vertex z coordinates is simply an initial value, not
a formula that would get re-evaluated if "height" changed. Changing a "radius"
parameter would have an effect since "radius" is used in constraint 1,
but since I don't ever recall wanting to change the radius at runtime,
I just stuck with a macro.
The faces are all carefully oriented so they have outward normals, so they
all contribute positively to the body volume. One should always check
that the initial volumes of bodies reported by the Evolver are what you expect.
Also, one can visually inspect the orientation of facets with a runtime
command "set facet frontcolor yellow".
The volume for the body is set to 1.3 times the cylinder volume, to
get a little bulge in the solder.
In the "read" section at the end of the datafile, the "hessian_normal"
command is a toggle that makes the "hessian" command work better by
restricting hessian motion to be perpendicular to the surface. This
is usually the thing to do, and it may become the default by the time
you read this.
The "gogo" command is a simple evolution script. It starts with a "u"
command for equiangulation, which here happens to nicely switch the
vertical edges to horizontal, a much better triangulation for this
surface. Because this surface is so simple and well-behaved, the
script is very simple. The "hessian_seek" commands are doing the heavy-duty
work of convergence; the other commands are just to get ready to do
- It is wise to use "hessian_seek" instead of "hessian" since
"hessian_seek" will seek along the motion direction for the lowest energy,
which is a lot safer than "hessian", which just jumps to the predicted
- Note that at the end of running "gogo", the scale for the hessian_seek
commands is near 1. That means the actual minimum is near the predicted
minimum (the scale factor for the predicted minimimum is exactly 1.0), and
hessian_seek has worked very well.
- For more on the "hessian" and "hessian_seek" commands, see the
documentation for Evolver.
BGA example home page
Next BGA page
Surface Evolver home page
More Surface Evolver examples
Ken Brakke's home page
This page last modified June 2, 2013