The dynamic relaxation is applied to all the nodes. The user seems to want to prevent the advection during the relaxation. If so, START in *CONTROL_ALE could be used. However, if I remember well, the run starts right away after the relaxation at t=0.0. *BOUNDARY_PRESCRIBED_MOTION_SET with SDIR=1 in *DEFINE_CURVE could be applied to prescribe zero velocities to ALE nodes during the relaxation. Nicolas On 11/15/2017 09:51 AM, LSTC Technical Support wrote: Hi Nicolas, Is there an option to exclude ALE parts from the dynamic relaxation (DR) process when a model involves ALE? Basically DR is turned off for ALE(?) but is still working for LAG parts? Ian Ticket#2017111410000251 --------------------------------------- On 06/14/2017 02:13 PM, Nicolas wrote: I've recently implemented a way to apply the dynamic relaxation to ALE model. Maybe the user should use the latest revision of the development version. _____________________________________________________________________ See also: http://ftp.lstc.com/anonymous/outgoing/support/FAQ/implicit.dynamic_relaxation http://ftp.lstc.com/anonymous/outgoing/support/FAQ/quasistatic http://ftp.lstc.com/anonymous/outgoing/support/FAQ/preload.tar _________________________________________________________________ Some examples illustrating explicit dynamic relaxation (DR): Stress and deformation is initialized in a spinning blade using DR: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/blade.dr.k Shell part is stretched during DR phase and then is impacted in transient phase: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/explicit_dr.k Bolt preloaded during DR phase using thermal loads: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/bolt.expl_dr.k Bolt preloaded during DR phase using *initial_stress_section: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/bolt.initial_stress_section.4not1.k.gz (NOTE: When using drdisp.sif data from an *initial_stress_section DR run in an initialization by prescribed geometry (IDRFLG=2), include *initial_stress_section and define the corresponding curve with IDRFLG=0 and the preload stress at full value but very briefly (~ 1 time step). Ticket 2017061310000076) Initialization due to gravity using DR: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/gravity_preload_by_dr.k.gz _____________________________________________________________________ Q: After the DR phase completes and I'm not satisfied that the solution is close enough to steady state, can I restart the DR solution with a tighter tolerance or otherwise let it run for a longer time? A: Yes. Submit a small restart using the d3dump written at the conclusion of the DR phase and a small restart input deck that includes *control_dynamic_relaxation with the modified DRTOL or DRTERM value. Or, if you don't want to modify the DR analysis and just want to immediately start a transient run that initializes from the final state of the DR run, omit *control_dynamic_relaxation from the restart input deck. ________________________________________________________________________ Q: If I want to use only one curve for dynamic relaxation and transient, can I give the same constant load both for dyn. relaxation and transient run using SIDR as 2? A: Yes, that will work in many cases but a ramp in the dynamic relaxation curve is preferred as it will induce less dynamic response and thus the dynamic relaxation phase will converge faster and be less likely to overshoot the real preload stresses. You want to minimize this 'overshoot' of stresses as it may take the material into a nonlinear regime which might otherwise not be breeched. ___________________________________________________________ Q: Dynamic relaxation is slow to converge in my model. Is there any way to speed it up? A: It's tricky and often iterative to attain efficient convergence because the convergence of an explicit dynamic relaxation solution is affected by not only ramp time of the load, but also time step size and the natural frequency of the system being modeled. It helps to bear in mind that the "damping" applied by DR is simply a scaling down of nodal velocity every time step and convergence is judged based on the current "distortional" kinetic energy as compared to the high tide value of "distortional" kinetic energy. (Ticket#2018021310000134) By postprocessing d3drlf and the ASCII relax data, we can determine if it's reasonable to terminate the dynamic relaxation phase prior to the default, distortional-kinetic-energy-based convergence criterion being satisfied. In other words, plot time histories from the d3drlf database (*database_binary_d3drlf) to see if a solution reasonably near steady state is attained,i.e., displacement and/or stress time histories have "leveled off" to near constant values. You can do this postprocessing while the job continues to run. If you decide it's OK to end the DR phase, make a note of the time in the DR phase, and issue an "sw1" sense switch to stop the run and write a d3dump01 file. Submit a small restart using a restart input deck that sets the appropriate DRTERM in *control_dynamic_relaxation. Plotting velocity vectors using the d3drlf database may help to isolate the region where kinetic energy is not reducing in a timely manner. You can then focus on this region in seeking a remedy, e.g., by including contact damping (VDC). If DRFCTR is too small, deformation may be overly inhibited A symptom of this is if the "convergence" time history (plotted using the ASCII output file "relax") has bottomed out at too high a value. On the other hand, the "convergence" value decreasing very, very slowly so that convergence takes too long may indicate the DRFCTR is too high (too close to 1.0). Slow convergence in explicit DR is especially common in large structures with low natural frequencies. This is because it takes a long time for the structure to respond in its fundamental mode. Depending on the size of the explicit time step, convergence of dynamic relaxation could take millions of time steps, if it converges at all (overdamping may be an issue). A good alternative may be to use implicit dynamic relaxation. See http://ftp.lstc.com/anonymous/outgoing/support/FAQ/implicit.dynamic_relaxation For this approach, you should use a double precision executable of LS-DYNA. See also http://ftp.lstc.com/anonymous/outgoing/support/FAQ/implicit_guidelines . Since none of the common ASCII output files, e.g., glstat, matsum, elout, are written during DR, it may be helpful to set IDRFLG to -1 at *CONTROL_DYNAMIC_RELAXATION and specify *DATABASE_BINARY_D3THDT. This will generate a binary file, d3thdt, that you can open in LS-PrePost using File -> Open -> Time History File. In order to see nodal or element data, you will still need to select these with *DATABASE_HISTORY_option. See also IDRFLG=3, which allows you to choose a part set on which to base convergence checking. NOTE: The associated DRPSET also controls which parts are included in the DR analysis; see http://ftp.lstc.com/anonymous/outgoing/support/EXAMPLES/bolt.initial_stress_section.4not1.idrflg3.k and bolt_idrflg3.png. Ticket#2018042510000028 (Manual modified by ub.) __________________________________________________________ Subject: springback via DR For a material that is implemented for implicit, I might suggest that implicit analysis be used to calculate the recovered state after each impact. For materials not yet implemented for implicit, explicit dynamic relaxation could be used for a springback simulation. The two files listed below illustrate springback (recovery) via dynamic relaxation (DR). First, run shells.dynain.k to simulate the first in a potential series of dynamic events. Because the command *interface_springback_lsdyna is included, a dynain file containing keyword commands representing the final state is produced. Next, run shells.dr_springback.k. This model uses the dynain data from the first run to initialize things and then simulates springback via DR. In the DR run, the termination time can be set to zero. DR is activated by setting SIDR to 1 in any load curve -- in this case a dummy load curve is used. The results of the springback analysis will be in the d3drlf database. The dynain file written from the springback analysis can be used in a simulation of the next event. Dynain files can be used in this sequential manner to simulate a series of events. See: http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.dynain.k http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.dr_springback.k _______________________________________________________ There are at least three approaches to preloading a system due to gravity. These all use the *load_body command. I would recommend the following: - Use dynamic relaxation to run a precursor, quasi-static analysis wherein gravity is ramped up to preload the structure. This involves defining 2 curves of acceleration vs. time. For the curve designated in the LCID field of *load_body, set (in *define_curve) SIDR to 0 and prescribed a constant acceleration vs. time. For the curve designated in the LCIDDR field of *load_body, set SIDR to 1 and linearly ramp the acceleration from zero to the constant (gravity) value over a short period of time (say 10 ms) and then hold it constant. Alternate approaches are ... - Run an implicit static analysis to preload the structure. - Invoke mass damping in the early portion of an explicit dynamic analysis to preload the structure and then release the damping and introduce the dynamic loads. __________________________________________________________________ Other comments regarding dynamic relaxation: Used to impose a preload. Not intended for loads that create large displacements. To invoke DR, the SIDR flag in any of the *define_curves is set to 1 or 2. *control_dynamic_relaxation is optional. It's used to change default values of dynamic relaxation control. A short ramp time of the loads applied during DR, e.g., over 1000 timesteps, is preferable to applying the load instantaneously. The load ramping will help to reduce dynamic effects. ---------------------------- Q: What is the meaning of this warning ... *** Warning 40515 (SOL+515) Velocities cannot be reinitialized after restart to account for geometry changes whenever: 1. "INIT" option is specified on command line during the initial run. 2. dynamic relaxation restart dumpfile is used to restart run. A: think I now understand the meaning of Warning SOL+515. Consider a case where a spinning body is initialized using *load_body_rx(y,z) in the dynamic relaxation phase. In the transient phase of the solution, *load_body_rx(y,z) is replaced with *initial_velocity_generation so as to initialize the spin of the preloaded body. In such a case, it is proper to set PHASE=1 in *initial_velocity_generation so that the deformed geometry is considered when assigning initial velocities to nodes. If PHASE is set to 0, you'll get Warning 5515. My best guess at what Warning 5515 is conveying... 1. The user has incorrectly set PHASE=0. 2. If the user attempts to remedy the situation by running a full restart from d3dump01 while setting PHASE=1 in *initial_velocity_generation in the full restart deck, PHASE will still be taken as 0 and the initial velocities will be still be based on the undeformed geometry. Attached is a 2-step example illustrating my hypothesis... 1. ls-dyna i=warning_SOL+515.k (Warning is written because PHASE=0 in trial.k). 2. ls-dyna i=warning_SOL+515.fullres.k r=d3dump01 (PHASE=1 in trialfullres.k) From postprocessing d3plot after step 2, I see the initial velocities at t=0 are still based on the undeformed geometry and the vm stress oscillates accordingly. If you were to go back and set PHASE=1 in the original input deck warning_SOL+515.k and skip step 2, the initial velocities are based on the deformed geometry and the vm stress in any element is nearly constant during the transient phase. http://ftp.lstc.com/anonymous/outgoing/support/FAQ/warning_SOL+515.tar