Anders Jernberg of ERAB recently provided us this very nice
presentation regarding termination time:

The first rule is that you wish to set it to as low as
possible to reduce simulation time. There are basically two
reasons for why the termination become a certain value.

1. You might want to simulate some short (in time) physical
phenomena where dynamic effects are essential for the
behavior, like car crash, hitting a golf ball or whatever.
Here you have to estimate for how long you need to perform
the simulation to catch the behavior you wish to analyze. That
estimation sets the termination time.

2. You wish to perform an analysis where you don't want the
inertia effects to affect the results, like applying a static
load to a structure. Running the explicit solver and applying
the load too fast you will get inertia effects that changes
the structural response. Applying a load very fast, and it
finally becomes more like an impact simulation. I believe the
best way to apply a load for (explicit) static analysis is to
ramp it up to the final load using a half sine function shape
for the load. The duration for the ramp-up time to get
reasonable small kinetic energy compared to internal energy
correlates to the eigenfrequency of the system. A minimum
reasonable ramp-up time for quasi static analysis is 1.5-2.0
times the normal period (1./frequency) of the system. That
sets the termination time in this case.

You can reduce the cpu time by allow mass scaling. For quasi-
static analysis, I believe selective mass scaling is superior.
It will not let you set shorter termination time but the time
step can be larger.

*** end Anders comments ***
__________________________________________________________________________

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 notes in text file "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.

It's important to understand that element size affects the explicit time step size 
(or added mass in the case of a mass scaled solution).  The smaller the element, the 
smaller the explicit time step (or the greater the added mass).  Thus excessive mesh 
refinement is detrimental to run time in two ways: (1) time step is reduced (or added
mass is increased), and (2) more elements much be processed.  

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).
Explicit/implicit switching is discussed in the
following archived FEA Information newsletter...

http://www.feapublications.com/pages/pdfnews/3feadec.pdf


See also:  mass_scaling, quasistatic.