Gull Wing Lead Example gullwing-1 for the Surface Evolver

r>
This first file does just the pad and lead geometry, without any solder. As a result, there is no energy to optimize. The geometry set up in this file will serve just as display in the later files, so one can see the pad and lead. This is the time to get various geometry decisions made before things get too complicated.

Design steps:

• General:
  • The first decision is the orientation of the lead. I choose to center the pad and lead lengthwise along the y axis, so I see a side view when it loads in the Evolver. On initial loading, the x axis is out of the screen, and the y axis is to the right. The horizontal section of the lead is down the negative y axis (leftwards), and the join to the circular part is at y = 0. "Toe" will refer to the negative x end of pad and lead, "heel" will refer to the positive y end (chip end).
  • If the geometry were always to stay symmetric about the x = 0 plane, then we could save about half in storage and execution time by doing just half the lead and pad. But we will later want to break the symmetry to calculate the force in the x direction, so we do a full geometry.
  • The geometric dimensions are defined as Evolver parameters. Most of them could be defined as macros, since they are mostly used as initial values and changing them at run time would not have the desired effect. Moving things around will be done by explicitly moving vertices, rather than just changing parameter values. The advantage of having them as parameters is that their values are accessible by name at run time.
• The pad:
  • The solder-wettable contact pad on the substrate will be at z = 0. It will be a rectangular pad, and its dimensions are given by parameters in the datafile (lengths in mils, remember):

      parameter padtoe   = -36 // x coordinate of pad toe end.
      parameter padheel  = 15  // x coordinate of pad heel end.
      parameter padwidth = 14  // full y width of pad.
    

  • The pad definition takes four vertices, four edges, and one face. All are fixed, since we do not intend for them to move. Also, the edges and face are marked as no_refine, since there is no point in refining a fixed flat triangle. The face is colored green for display purposes.
  • The pad facet tension is set to zero in the read section of the datafile, along with the other display facets, since these facets are purely for display and have nothing to do with energy calculations.
• The lead:
  • The curved portion of the lead is modeled with circular arcs. Other curves, such as parabolas or sine waves, could have been used, but it is simplest to get constant thickness with circular arcs.
  • There are six parameters defining the shape of the lead:

       parameter thick = 6         //Thickness of lead in the z direction.
       parameter width = 10        // Width of lead in y direction
       parameter leadtoe = -30     // Toe of lead, relative to heel 
       parameter bend = 90*pi/180  // bending angle of a curved section, radians
       parameter rad = 10          // inside radius of bends
       parameter orad = rad+thick  // outside radius of bends
    

    Note that the bend angle is expressed as degrees converted to radians, since Evolver uses radians in trig functions. Leadtoe is actually the negative length of the horizontal part of the lead.
  • The position of the lead is defined by three parameters:

       parameter gap  = 5 // Height of the bottom of the gull foot above the pad
       parameter leadheel = 0  // y coord of flat-curve junction of lead
       parameter leadshift = 0 // x offset of centerline of lead
    

    These are the only parameters that should be changed at runtime to move the lead, and even then the changing should only be done by the carefully defined movement commands discussed below.
  • The curved surfaces of the lead are defined by four level-set constraints:

       constraint 1  // lower side of lower curve
       formula: (z-(gap+orad))^2 + (y-leadheel)^2 = orad^2
    
       constraint 2  // upper side of lower curve
       formula: (z-(gap+orad))^2 + (y-leadheel)^2 = rad^2
    
       constraint 3 // lower side of upper curve
       formula: (z-(gap+(rad+orad)*(1-cos(bend))-rad))^2 +
                     (y-leadheel-(rad+orad)*sin(bend))^2 = rad^2
    
       constraint 4 // upper side of upper curve
       formula: (z-(gap+(rad+orad)*(1-cos(bend))-rad))^2 +
                     (y-leadheel-(rad+orad)*sin(bend))^2 = orad^2
    

    Constraints 1 and 3 could have been combined into one constraint using conditional expressions, as could 2 and 4, but there is no real point in getting that fancy here.
  • These constraints will be used only for the display surface. Constraints with the same formulas will be defined later for the solder. It is generally wise to keep separate constraints for display surfaces and energy surfaces.
  • No constraints are defined here for the flat surfaces of the lead, since refining keeps them flat, and the movement commands are guaranteed to keep them flat.
  • I made a hand sketch to number all the vertices, edges, and facets, and typed them all in. The faces are all oriented with outward normal. This is not strictly necessary, but I felt like doing it that way.
  • I did not make the lead edges and faces no_refine since at least the curved surfaces must refine in order to follow the circular arcs.
  • The lead faces are all colored yellow, suggestive of gold, and distinct from the white that the solder surface will be.
• The read section: .
  • This section of the datafile gets executed after the surface is set up, just as if the user had typed it in at the command prompt. Two types of things happen here: commands that execute immediately to initially massage the surface, and definitions of commands the user can run later.
  • The first massaging done is to fix up the triangulation on the sides of the curved parts of the lead:

       // Subdivide some curve edges for better display
       refine edge where (id >= 17 and id <= 20) or (id >= 23 and id <= 26)
    
       // Get rid of pesky vertices in middle of curved sides.
       delete edge ee where sum(ee.facet,color==yellow)==2 and ee.length < thick/3
       foreach facet ff where color==yellow do { fix ff.edge; fix ff.vertex; fix ff}
    

    The problem is that the original triangulation upon loading can put a vertex too near the inside arc, and later refining creates facets that cut across the arc. Try commenting out the refine line and see what refining does. The use of hardwired edge numbers might be considered poor programming style, but it is the easiest way to identify these particular edges, and the numbers are not likely to change in the later datafiles of this series. The delete command gets rid of a couple of short edges. Since delete won't delete fixed edges, the side faces were left unfixed in the Faces section. The last command takes care of that.
  • Next come some commands to move the lead in three directions. For example, translation in x is done by:

       delta_x := 0
       move_x := { leadshift := leadshift + delta_x;  // do parameters first
                   set vertex x x+delta_x where z > 0;
                 }
    

    The movement is relative, of magnitude delta_x. Note that delta_x is used in an immediately executed assignment statement so the parser has a declaration of it before its use in move_x and the user can set delta_x before invoking move_x. In move_x, the leadshift parameter is changed first, because setting a vertex coordinate value causes immediate projection to any constraints it is on, and we want those constraints to be in the new position.
• Frills:
  • To reduce the display to just a wire-frame outline, the file outline.cmd contains a command outline:

       outline := { dissolve facet where color==yellow or color==green;
                    foreach edge ee where original == -1 and valence == 0 do
                       { unfix ee; dissolve ee }
                  }
    

    The dissolve command simply eliminates objects without collapsing them (as delete does). It will not dissolve vertices still used by edges, or edges still used by facets. It will (as of version 2.14) dissolve facets used by bodies. An original number of -1 is assigned to edges that are produced by subdividing facets; the condition is used to prevent dissolving the edges descended from those originally in the datafile. The unfix is necessary since fixed edges will not be dissolved.
  • For later use in totally eliminating all display elements, outline.cmd also contains the command vanish:

       vanish := { outline;
                   dissolve edges;
                   dissolve vertices;
                 }
    

  • To refine the lead to smoothness with the minimal number of elements, the file slats.cmd contains the command slats. This command refines the curved edges and faces in such a way as to create a lot of thin, horizontal triangles, and then fixes the display facets so refining won't affect them.
  • Both of these files are automatically read in at the end of all the datafiles in this series.