Checklist for Implicit Modelling

  • When run­ning im­plic­it mod­els, al­ways use a dou­ble pre­ci­sion ex­e­cutable.
  • Be­cause the im­plic­it solver con­tin­ues to evolve and im­prove, the lat­est pro­duc­tion re­lease list­ed in ver­sions is rec­om­mend­ed. For ex­am­ple, start­ing with the R11 branch, a new, more con­ve­nient im­plic­it mem­o­ry scheme is im­ple­ment­ed. With this scheme, you will be in­formed of the min­i­mum mem­o­ry re­quire­ment with the "Im­plic­it Us­age Alert."
  • To get the very lat­est im­prove­ments, you can try the lat­est De­vel­op­ment ver­sion, that is, "ver­sion dev." To down­load ver­sion dev, send an email to sup­port@lstc.com and pro­vide the ban­ner from one of your mes­sag (SMP) or mes0000 (MPP) files.
  • For mild­ly non­lin­ear prob­lems, use NSOLVR = 12 with LSMTD = 4 (*CON­TROL_­IM­PLIC­IT_­SO­LU­TION).
  • For high­ly non­lin­ear prob­lems, use NSOLVR = 12, ILIM­IT = 1 to in­voke the Full New­ton method, and LSMTD = 4. Bump­ing LSMTD from 4 to 5 may rarely of­fer some ben­e­fit.
  • Set AB­STOL =  in *CONTROL_IMPLICIT_SOLUTION to prevent premature convergence.
  • For non-tied con­tacts, use MOR­TAR type con­tacts.
  • For tied con­tact, fol­low Re­mark 4, "Tied Con­tact Types and the Im­plic­it Solver" in the *CON­TACT sec­tion of the lat­est DRAFT of the User's Man­u­al (www.lstc.com/­down­load/­man­u­als).
  • Set VDC = 0 in *CON­TACT cards.
  • Set OSU = 1, INN = 4, and IACC = 1 in *CON­TROL_­AC­CU­RA­CY.
  • El­e­ment for­mu­la­tions:
    • Use ELFORM = -16 for shells (that's neg­a­tive 16), and ap­ply hour­glass type #8.
    • Use sol­id ELFORM = -2 for sol­id hexa­he­dral el­e­ments, es­pe­cial­ly when the sol­id el­e­ments have bad as­pect ra­tios.
    • Use ELFORM = 2 in­stead of ELFORM=13 for beams.
    • For a con­ve­nient way to change el­e­ment for­mu­la­tion for im­plic­it, see the vari­ables ISOL­ID, IBEAM, ISHELL, and IT­SHELL in *CON­TROL_­IM­PLIC­IT_­EIGEN­VAL­UE.
  • If there are *RIGID­WALLs, set RW­P­NAL to -1.0 (that's a neg­a­tive one).
  • In­voke the non-sym­met­ric solver by set­ting LCPACK = 3 in *CON­TROL_­IM­PLIC­IT_­SOLVER if con­ver­gence is a prob­lem, and
    • damp­ing is in­clud­ed in an eigen­val­ue analy­sis (in this case, use SMP on­ly),
    • MOR­TAR con­tact with fric­tion is in­clud­ed,
    • beam for­mu­la­tion 2 is used, or
    • oth­er less com­mon con­di­tions that have a non-sym­met­ric con­tri­bu­tion as enu­mer­at­ed in the User's Man­u­al ex­ist (*CON­TROL_­IM­PLIC­IT_­SOLVER).
  • im­pl­stat_­v2.0_­in_­lspp.pdf de­scribes how to gen­er­ate im­plic­it sta­tis­tics plots from d3hsp us­ing LS-Pre­Post.
  • If a fa­tal er­ror mes­sage that men­tions the solver is en­coun­tered, set LPRINT = 3 in *CON­TROL_­IM­PLIC­IT_­SOLVER and then look for added in­for­ma­tion in the mes* file(s) that pro­vides fur­ther de­tails con­cern­ing the source of the prob­lem.
  • If an im­plic­it analy­sis is shar­ing com­put­ing re­sources with oth­er LS-DY­NA runs and/­or with oth­er ap­pli­ca­tions, and a mem­o­ry re­lat­ed er­ror oc­curs, try re­duc­ing RD­CMEM in *CON­TROL_­IM­PLIC­IT_­SOLVER from the de­fault of 0.85 to 0.50. This ad­vice ap­plies start­ing with ver­sion R11.
  • Be­fore run­ning an im­plic­it sta­t­ic analy­sis, it's good prac­tice to run an eigen­val­ue analy­sis to de­ter­mine if the mod­el has any rigid body modes. If such modes ex­ist they need to be con­strained out or *CON­TROL_­IM­PLIC­IT_­DY­NAM­ICS needs to be ac­ti­vat­ed (to run a dy­nam­ic analy­sis rather than a sta­t­ic analy­sis).

Other Sources of Information about Implicit Modeling in LS-DYNA

  • Ap­pen­dix P,  "Im­plic­it Solver" in the User's man­u­al gives an overview of and pro­vides a more com­pre­hen­sive "Check­list" for im­plic­it mod­el­ing. 
  • In­for­ma­tion on im­plic­it mod­el­ing is al­so pro­vid­ed at dy­na­sup­port im­plic­it.  In par­tic­u­lar, the zip file at dy­na­sup­port in­cludes a com­pre­hen­sive im­plic­it guide­lines doc­u­ment LS-dy­na_­im­plic­it_­guide­line.pdf, as well as ex­am­ples that are de­scribed in a readme.txt file.
  • For the­o­ret­i­cal in­for­ma­tion about the im­plic­it solver in LS-DY­NA, re­fer to the fol­low­ing sec­tions in the lat­est DRAFT of the The­o­ry Man­u­al:
    • Sec­tion 29.21, "Mor­tar Con­tact"
    • Sec­tion 37, "Im­plic­it"
  • Ad­di­tion­al ex­am­ples fea­tur­ing im­plic­it analy­sis are avail­able at dy­naex­am­ples.

Comments

Post a Comment

Popular posts from this blog

Delamination and Tiebreak Contact

Although the jury is still out, I think people are finding tiebreak contact to be less problematic than cohesive elements. Section 3.5.1, "Composite Delamination", of the Modeling Guidelines Document (MGD), available under "Resources" at http://awg.lstc.com, offers some pertinent tips. See also the example "Ballistic Impact on Composite Plate" at http://awg.lstc.com/tiki/tiki-index.php?page=QA+test+example+7. First of all, for modeling delamination, you'd need to model each ply with a layer of elements. *contact_automatic_one_way_surface_to_surface_tiebreak with OPTION 6,7, or 9 (solids) One approach would be to model a layer of shell or solid elements for each composite layer and bond the layers with a tiebreak contact, e.g., or OPTION 8,10, or 11 (shells). input variables in *mat_138 as follows: Refer to *mat_138 for a detailed description of t...
Read more

Cylindrical Coordinate Systems

Cal­cu­la­tions in LS-DY­NA are al­ways com­put­ed in a Carte­sian co­or­di­nate sys­tem. In cas­es where a cylin­dri­cal mod­el set­up is re­quired, a num­ber of lo­cal Carte­sian co­or­di­nate sys­tems may be de­fined to ef­fec­tive­ly mim­ic a cylin­dri­cal co­or­di­nate sys­tem. LS-Pre­Post can fa­cil­i­tate this process as well as dis­play most re­sults in an al­ter­na­tive lo­cal Carte­sian, cylin­dri­cal, or spher­i­cal co­or­di­nate sys­tem. Input in a cylindrical coordinate system Cer­tain LS-Pre­Post En­ti­ty Cre­ation tools have a Cylin­dri­cal CS op­tion to au­to­mat­i­cal­ly de­fine and ref­er­ence a set of lo­cal Carte­sian co­or­di­nate sys­tems in cas­es where a cylin­dri­cal co­or­di­nate sys­tem is re­quired. *BOUND­ARY_­SPC Mod­el → CreEnt → Bound­ary → Spc → Cre. Se­lect the ra­dio but­ton Set or Node (see Set vs. Node/­Point se­lec­tion note be­low). Se­lect the check box named Cylin­dri­cal CS. Se­lect (and cre­ate if nec­es­sary) a CID and a di­rec­tion in that C...
Read more

Energy Balance

Total energy reported in GLSTAT (see *database_glstat) is the sum of the following:   - internal energy (includes "eroded internal energy") - kinetic energy (includes "eroded kinetic energy") - sliding interface energy (better known as contact energy) - hourglass energy (starting at rev. 83861, includes "eroded hourglass energy") - system damping energy - stonewall energy (better known as rigidwall energy)   "Spring and damper energy" reported in the glstat file is the sum of internal energy  of discrete elements, seatbelt elements, and energy associated with joint stiffnesses  (*constrained_joint_stiffness....).   "Internal Energy" includes "Spring and  damper energy"   as well as internal energy of all other element types.  Thus "Spring and damper energy" is a subset of "Internal energy".   Two energy terms are written to jntforc in 971 R3.    The first term "energy" is new...
Read more