When running explicit simulations in LS-DYNA, it is very important to understand the total CPU clock and the total Elapsed time used by the solver. This information is available at the bottom of every D3HSP file written by LS-DYNA as shown below. The total elapsed time reported in the file is the difference between the times of termination and execution. This report of Elapsed time is a static number and gives a good overview of the turnaround time for the simulation. It however, lacks the ability to provide insight at incremental intervals that is sometimes very useful to verify that it did not spend too much time during the solution. There are two ways to view incremental elapsed time and they are briefly discussed below.

1. Time Per Zone Cycle (TZC) in GLSTAT output
LS-DYNA outputs a variable called ‘Time per zone cycle’ in nanosecond as a function of simulation time into the file GLSTAT. TZC represents the elapsed clock time for each cycle at the time of output and can be plotted as a function of the simulation time in any pre-processor.

2. Incremental Elapsed Time based on D3PLOT File TimeStamp
To better understand the turnaround time, we can use the TIMESTAMP of the D3PLOT files (output at least 10 per simulation using a frequency of ENDTIM/10) and plot the incremental time difference using two successive D3PLOT’s TIMESTAMP starting from the first D3PLOT. For example, if we have 10 states of information (D3PLOT[geometry], D3PLOT01, D3PLOT02, ….., D3PLOT10), then the successive incremental elapsed time can be computed by taking the TIMESTAMP difference of D3PLOT01_TIMESTAMP, D3PLOT02_TIMESTAMP-D3PLOT01_TIMESTAMP, ….., D3PLOT10_TIMESTAMP-D3PLOT9_TIMESTAMP. This information can then be plotted against the respective actual simulation time at which the D3PLOT was written as shown below.

(Click image to enlarge)

There may be several factors that could lead to slower progression when compared with the starting point. Dropping timestep, adaptivity (where more elements are being added dynamically), varying contact-impact conditions are some of the few possible causes. Some of the causes may be unavoidable, such as adaptivity, but other causes such as dropping timestep or inappropriate contact defintions which could lead to large bucket-sizes must be reviewed and fixed to improve the overall job turnaround time. Since we run a number of design iterations over the course of the product design cycle, any improvement early on during the debugging phase can signficantly improve the overall turnaround time.