Ball Grid Array Example bga-1 for the Surface Evolver

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.	After gogo.

Notable features:

• 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 the Evolver.
• 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 hessian_seek.
• 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 minimum.
• 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 hessian documentation for Evolver.