Gull Wing Lead Example gullwing-4 for the Surface Evolver

This datafile does some final polishing, particularly of the undercutting in the toe and heel. Also, it demonstrates the use of Hessian commands, and does some investigation of numerical accuracy.

Design steps:

• 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.