Like *contact_automatic_single_surface, *contact_automatic_general is a single surface contact, that is, the contact is defined wholly by the slave side. Both contact types consider shell thickness and beam thickness, that is, the contact surface is offset from the shell midplane and from the beam centerline. The beam cross section, for contact purposes only, is idealized as circular. At shell edges, the contact surface wraps around in a circular arc thus joining the contact surface on one side of the shell to the contact surface on the opposite side. One important way in which an automatic_general contact differs from an automatic_single_surface contact is the way in which beam contact and shell edge contact are handled. *Contact_automatic_general contact checks for penetration along the entire length of exterior (unshared) shell edges. By adding the option _INTERIOR to *contact_automatic_general, interior (shared) shell edges are also checked for edge-to-edge penetration. For this to apply to solid surfaces, you would need to coat the solid surface with *MAT_NULL shells and include the part ID of the null shells on the slave side. Put another way, think of *contact_automatic_general as adding null beams to the exterior edges of shell parts so that edge-to-edge treatment of the shell parts is considered by virtue of beam-to-beam contact of the automatically-generated null beams. By adding the word INTERIOR, the contact algorithm goes a step further by adding null beams to all the shell meshlines, both exterior AND interior. Another distinction is in the value of penetration that triggers release of the penetrating node from contact consideration (see Table 6.1 in the Keyword User's Manual). For automatic_general contact, that value is effectively unlimited whereas automatic_single_surface contact will release the penetrating node after it penetrates approximately half an element thickness. Yet another distinction is that, by default, automatic_general contact checks for nodal penetration through the three closest segments ("search depth" = 3) whereas automatic_single_surface checks only two segments. The three segment check is more expensive but may be more robust for contact in corners. The default "search depth" for any automatic contact may be overridden on optional card A of *contact. The segment-based alternate penalty formulation (invoked by setting SOFT = 2 on optional card A of *contact) is available for automatic_single_surface but not for automatic_general_contact. Setting SOFT=2 in an automatic_single_surface contact changes the contact algorithm altogether. (See separate notes on SOFT=2 contact or go to www.lstc.com/pages/help.) To write contact forces produced by any single surface contact to the RCFORC file, one must define a *contact_force_transducer_penalty. ___________________________________________ IGNORE flag in type 26 contact: *** UPDATE per jpd 6/8/07 *** IGNORE=1 has a different effect in *contact_automatic_general depending on whether you're running SMP (IGNORE is always internally reset to 0 and thus nodes are moved to reduce or eliminate initial penetrations) than in MPP (IGNORE=0 and IGNORE=1 work as advertised, or at least they do in the attached example using 971/7600.1077)). ~/test/shl2sol/sphere_to_plate.examine_ignore_type26.k *** per JOH 8/2004 *** We are aware that, as currently implemented in LS-DYNA, the effect of IGNORE on type 26 contact is different depending on whether an SMP or MPP executable is used. SMP: IGNORE=1 is disregarded for type 26 contact MPP: IGNORE=1 is considered for type 26 contact in the sense that initial penetrations are not moved but then contact forces are immediately applied. This discrepancy is unlikely to change in the near future. Please avoid using IGNORE=1(or 2) for type 26 contact. To John 8/26/04: Rather than making a note in the User's Manual which a user may not notice, can I request that you modify the source code so that IGNORE is automatically set to 0 for *contact_automatic_general. That way, there's less chance of SMP and MPP giving different results. A warning message should also be written so that the user knows IGNORE was automatically changed. jpd