- Toe undercutting. To prevent toe undercutting in a better way,
we are going to force certain vertices and edges of the solder surface to
align with the toe corners, and constrain those vertices and edges to
stay outside of the lead. First, constraints 31 and 32 to keep
the upper parts of edges 47 and 48 (the vertical edges at the toe
of the solder) aligned with the sides of the lead:
constraint 31 // +x side of lead
formula: z >= gap/2 ? x = leadshift + width/2 : 0
constraint 32 // -x side of lead
formula: z >= gap/2 ? x = leadshift - width/2 : 0
The 0 part of the conditional formula is effectively a
non-constraint, since it is trivially satisfied by any vertex.
It turned out insufficient just to align vertices for z >= gap.
Now vertices on these constraints can be forced to stay beyond the
toe with constraint 33:
constraint 33 nonpositive // keep in front of toe above gap
formula: z >= gap/2 ? y - (leadtoe+leadheel) : -1
This works pretty well, permitting us to remove the fixing of vertices
25 and 26 from gogo.
- Heel undercutting. Similar treatment is given the heel.
The back vertical edges are also placed on constraints 31 and 32
respectively, and constraint 34 keeps the vertices outside the heel:
constraint 34 nonpositive // keep under heel
formula: z - ZLOWER
- True undercutting. If the solder volume were low enough that
the solder really does undercut the toe, then a more elaborate model
would be needed, since a bit of the underside of the lead would be left
bare, in the same way bits of the pad are bare in the corners.
- Hessian commands. Using gradient descent, it is difficult
to judge when the surface has converged. Therefore, the Evolver has
some commands using second derivatives. Since the matrix of second
derivatives is called the Hessian matrix, these commands as a group
are called the Hessian commands. They can be used to test for the
presence of an energy minimum and quickly converge to that minimum.
- Eigenprobe. "Eigenprobe t" will report the
number of Hessian eigenvalues below, equal, and above the value t.
If all eigenvalues are positive, the Hessian is positive definite, which
is necessary at an energy minimum.
- Eigenvalues. If you are interested in actual eigenvalues,
the command "ritz(t,n)" will calculate the n eigenvalues nearest t.
Keep n small, like 5 or 10 at most. Also, to properly compare
eigenvalues at different refinements, you should have the linear_metric
option on (it is turned on in gullwing-4.fe). To see the eigenvector
displacements corresponding to eigenvalues, see the documentation for
the hessian_menu command.
- Hessian. The hessian command itself calculates the
energy minimum from the Hessian matrix and the gradient, and moves the
surface there. This should be used only when near the minimum, and when
the Hessian is positive definite. Even then, strange things can happen,
so be cautious. Save your surface, unless you are willing to re-evolve.
The hessian_seek command is more forgiving, acting like the
g command in moving in the direction calculated by the hessian
only to the low point of energy.
- Hessian_normal. It turns out that sideways slithering of
vertices on a surface gives rise to lots of small negative eigenvalues
that are really, really hard to get rid of by evolution. Since these
motions don't much affect the surface energy, I have found it best to
have Hessian commands consider only motions perpendicular to the surface.
This is done when hessian_normal mode is set, which is done
by default in Evolver version 2.14 and later. But the hessian_normal
command is still in these gullwing datafiles for use in older Evolvers.
- Nailing. One situation not handled well by hessian_normal
mode is vertices hitting one-sided constraints, particularly when
the vertices wind up confined to a line, as when the solder contact
line hits the top of the lead. Therefore, I have found it prudent to
fix such vertices, and I call the command to do this nail:
nail := { constraint_tolerance := 1e-2;
g; // to get hit_constraint to use new constraint_tolerance
fix vertex where hit_constraint 6 or hit_constraint 7 or
hit_constraint 20 or hit_constraint 21 or hit_constraint 22
or hit_constraint 23 or hit_constraint 33;
fix vertex where id>=25 and id<=28;
constraint_tolerance := 1e-12;
}
The constraint_tolerance internal variable is the criterion
by which the Evolver judges whether a vertex has hit a constraint.
It turned out the default value of 1e-12 was not quite small enough
for certain vertices.
There is also an unnail command to unfix all these vertices,
which should be used when further non-Hessian evolution is done, say
after refining.
- Example. Here's an example of evolving to convergence:
Enter command: outline
Enter command: gogo
(much output)
Enter command: nail
0. area: 1182.62391951408 energy: -148.290414019104 scale: 0.548760
Fixed: 70
Enter command: g
0. area: 1182.61764555601 energy: -148.290552356250 scale: 0.615594
Enter command: nail
0. area: 1182.57887374083 energy: -148.291385388198 scale: 2.00000
Enter command: eigenprobe 0
Converting to all named quantities...Done.
Eigencounts: 0 <, 0 ==, 185 >
Enter command: hessian
1. area: 1182.38631123151 energy: -148.291436510627
Enter command: hessian
1. area: 1182.38666006866 energy: -148.291436511044
Enter command: hessian
1. area: 1182.38666212261 energy: -148.291436511044
When hessian works, it works very well, usually converging
completely in four or so iterations. Actually, only the energy has
converged completely here; a couple more iterations will converge the
area also.
- Symmetry. It may seem that since we are starting with a
mirror-symmetrical model, that it ought to be mirror-symmetrical at
all later stages. However, this is difficult to achieve for a
couple of reasons:
- Some commands, such as equiangulation and edge deletion, can
explicitly break the topological symmetry when they operate on edges
crossing the mirror plane.
- Computer arithmetic is not precisely associative. The force on
a vertex is calculated by adding the forces due to its adjoining facets,
and mirror vertices can get their facets in different orders (e.g.
clockwise order is different for the two vertics). This affects only
the most insignificant bit at first, but this tiny difference can get
amplified considerably as evolution continues.
The file sym.cmd contains some symmetry-related
commands. It shows that, even without any symmetry-breaking commands in
gogo, corresponding vertices are asymmetric by up to 0.01 mil.
- Numerical accuracy. Supposing that we are interested in
the accuracy of the force values, let's compare forces at successive
refinements.
After gogo and the Hessian convergence in gomore:
xforce: -0.00587398488960
yforce: -6.80646244092031
zforce: -31.75953513419927
After another refinement and more iteration (see the gogo2 command):
xforce: -0.00835102596852
yforce: -6.77895717956289
zforce: -31.87586150858124
After yet another refinement and more iteration (see the gogo3 command):
xforce: -0.00081057493162
yforce: -6.77176103820898
zforce: -31.92729134980255
One can get an idea of the accuracy of the forces from the x force, which
ideally would be zero due to symmetry. With the linear model, one can
generally expect an improvement by a factor of 4 in the force with each
refinement.
