When you’re using explicit time integration, there is no magic cure for long run times associated with simulating very small geometries over relatively long periods of time. Mass-scaling carries a burden of having to confirm that the addition of nonphysical mass does not significantly affect the results (see “mass_scaling”). A similar burden exists when time-scaling is employed. Time-scaling is a technique where the loading rate is increased and thus the simulation time is shortened in order to reduce the required number of timesteps.
Make sure that your timestep is not being controlled by only a few small or stiff elements by searching in the d3hsp file for the string “smallest”. If there are only a few controlling elements, you can remesh in the vicinity of those elements or perhaps make them rigid.
Though it’s rather obvious, run only as long as is necessary. This means in the case of a drop simulation, assigning an initial velocity to the dropped object and placing it a very small distance from the landing surface. After impact, run only long enough to get the results you need.
Be aware that for lengthy simulations where the number of timesteps goes above half a million or so, you’d be well advised to use a double precision executable of LS-DYNA to minimize error due to roundoff. Running double precision carries with it a cpu penalty of around 30%.
Automatic explicit/implicit switching may be an option. Using this technique, the user can specify time windows in which implicit time integration is used as opposed to explicit time integration. An advantage of implicit time integration is that timesteps are not tied to element size and can thus be much larger. Of course, an implicit timestep is also much more expensive in terms of cpu. Further, not all LS-DYNA features and materials are implemented for implicit analysis at this time (though most are).