Welcome to the LS-DYNA Product Space

<p>I'm installing LSDYNAR version 5.1.1, but the machine code fails to generate during the installation process. What could be causing this?</p>

<p>I was trying to figure out LS-DYNA would be available for piping stress analysis using Elbow Beam.</p><p>So, I made two models for the comparison between regular beam (ELFORM = 1) and elbow beam (ELFORM = 14) under *LOAD_BODY_Y with structural mass only.</p><p>I guess the deformed configuration of the regular beam seems reasonable while one of the elbow beam unrealistic.</p><p>I know elbow element is still in beta but I think I have to use elbow element to incorporate the pressure stiffening effect into the analysis.</p><p>Is it a bad idea to use LS-DYNA for piping stress analysis for now?</p><p>By the way, I have found the NSM field in *SECTION_BEAM for elbow element would not work properly. I got a overestimated physical mass in "messag" file.</p><p></p>

<p><p>I tested LSPP version 4.10 to 4.13 in 3 different computers, there are same problems. </p>

<p>Workbench 2025R2 start support Mat187L. In workbench it only provide 2 options for "the strain rate caculation"? EQ1 is best but missed. Can Ansys correct it in next version? </p>

<p>PLEASE REQUESTED SIR COMPELTE THE MY INTERNSHIP </p>

<p>Is there any reason that control_adaptive does not work with mat_add_inelasticity coupled with a hyperelastic material model?</p>

<p>How can I better understand below statement from the documentation about control_adaptive and hyperelastic materials?   Why is adaptive remeshing having problems with large deformation problems or with hyperelastic materail model?   I suspect it has to do with how strain energy potentials are implemented but I honestly have no idea and I would like to develop some basic understanding of why this is an issue and to what degree it is an issue?<br><br>Has anyone in Ansys done any studies that can be shared with me?</p><p></p>

<div>Link to my umat49v and Keyword files<br><br>Hello,</div><div> </div><div>I'm experiencing an issue with coupling a user-defined material (UMAT49V) to an equation of state in LS-DYNA R16.1. The EOS pressure array pc(i) accessed via common/eosdloc/ remains zero throughout the simulation, even though the configuration appears correct.</div><div> </div><div>Environment:</div><div>- LS-DYNA Version: R16.1-182-g5848067bc5 (MPP, Windows 10, Intel Fortran 19.0)</div><div>- Material: *MAT_USER_DEFINED_MATERIAL_MODELS (MT=49)</div><div>- EOS: *EOS_GRUNEISEN (EOSID=1)</div><div> </div><div>Configuration:</div><div>My material card is set up with:</div><div>- IEOS = 1 (EOS coupling enabled)</div><div>- NHV = 12 (reserved 4 slots for EOS as per manual)</div><div>- PART card references both MID=1 (UMAT) and EOSID=1 (EOS)</div><div> </div><div>In my UMAT49V subroutine, I access the pressure via:</div><div>text</div><div>  common/eosdloc/pc(nlq)</div><div>  ...</div><div>  p_eos = pc(i)</div><div>text</div><div> </div><div>Observed Behavior:</div><div>- Debug prints show pc(i) = 0.0 for all cycles</div><div>- The UMAT is being called (deviatoric stresses compute correctly)</div><div>- Time stepping is working (4347 cycles completed)</div><div>- Elements are deforming (strain increments are non-zero)</div><div> </div><div>What Works:</div><div>- MAT_010 (*MAT_ELASTIC_PLASTIC_HYDRO) with the SAME *EOS_GRUNEISEN card works correctly and produces non-zero pressure</div><div>- This confirms the EOS card itself is valid</div><div> </div><div>Question:</div><div>Is the common/eosdloc/pc() mechanism supported for *MAT_USER_DEFINED_MATERIAL_MODELS in R16.1? The manual (Appendix A, section on user materials with EOS) states that I should:</div><div>1. Set IEOS=1</div><div>2. Reserve first 4 history variables for EOS</div><div>3. Access pressure via pc(i)</div><div> </div><div>I've done all three, but pc(i) never gets populated. Is there a compilation flag, additional include file, or different approach needed for user materials to access EOS pressure in R16?</div><div> </div><div>Workaround Consideration:</div><div>Would implementing the EOS in dyn21ueos.f (using ueos41) instead of relying on external *EOS_GRUNEISEN cards be more reliable for user material coupling?</div><div> </div><div>Any guidance would be greatly appreciated. I can provide the full keyword file and UMAT code if needed for troubleshooting.</div><div> </div><div>Thank you,</div><div>Amrith<br><br><br></div>

<p>Hi everyone,</p><p>I’m working on a 2D axisymmetric hypervelocity impact simulation in LS-DYNA and am trying to apply non-reflecting boundary conditions to the outer edges of the target domain (bottom and right boundaries).</p><p>When I select all nodes along those boundaries and assign:</p>*BOUNDARY_NON_REFLECTING_2D <p>I receive the following error:</p>*** Error 21385 (STR+1385) The node set of *BOUNDARY_NON_REFLECTING_2D 1 has 2 non-consecutive nodes: 94606 94884 <p>However, if I apply the boundary card to only a single node on each boundary, the error disappears — but that clearly isn’t physically correct for wave absorption.</p><p>My understanding is that node numbering along the boundary must be sequential for NRBC to work correctly, but I’m not sure of the best practice to enforce this in a 2D axisymmetric mesh (e.g., whether to define separate segments, sort nodes, or restructure the mesh).</p><p>Could anyone please advise on the correct way to define non-reflecting boundaries for a 2D axisymmetric ALE/Lagrangian model? I’ve attached my keyword files at the link provided for reference.</p><p>Any guidance would be greatly appreciated!</p><p>Thanks,<br>Amrith<br><br>Keyword File</p>

Two 'Single ALE material' contained in a lagrangian shell conatiner and seperated by a lagrangian shell wall Both the ale material and lagrangian material have same or equivalent densityALE materials do not mixIs it possible to model Fluid solid interaction or ALE and Lagrangian coupling, when both the ALE and Lagrangian material have same or equivalent density?