While we live according to a single time measured by the clock
on the wall, in a simulation the definition of time is more complicated.
We define the time measures of interest as follows:
- this will be an increment in the actual clock time in the world
of the person running the simulation and on the processor clock.
- this is the time increment represented by the simulation. For
example, in a simulation of a planetary orbit, tsim
might represent a day or a week. In a simulation of an atomic
interaction, on the other hand, tsim
might represent a nanosecond or less.
- the time increment used in a numerical
calculation of the simulated phenomena over the time span of tsim.
To obtain an accurate simulation, dtcalc
must often be much smaller than tsim..
For example, in the case of a ODE
steps in the integration.
If we attempt to match tsim
to the tclock
time, we will say tsim
is simulating "physical time". So , for example, if we
simulate a ball dropping one meter and we drop a real ball from
a meter above the floor at the same moment we click on the Drop
button, then ideally both the real and simulated balls would hit
the floor at the same moment.
Perhaps all you need from your simulation is a simple final answer
such as the coordinates of the spot where a cannon ball will hit.
Usually, though, we want an animation of the whole process. In a
typical animation the program tries to draw the frames fast enough
to give the illusion of smooth continual motion. We define the programming
time increments involved in an animation as follows:
- the time between frames, such as 40 msecs to provide 25 frames
- this is the time needed to calculate the new arrangement of
objects in the frame, such as planets or atomic particles. Note
that some steps may require more computation than others and so
could vary from frame to frame.
- the time it takes to display the frame.
- the idle time between when the frame display and the start of
the next frame calculation.
- time taken up by the system when it stops the simulation to
go do other tasks. This also includes time taken up by other threads
within your program that you create to do parallel tasks.
The figure here shows graphically the relationships among these
|Figure: Time relationships
Before Java 1.2, animations required using the Thread
method (see Chapter
8: Java : Demo 1) to pause between the calculation and display
processing. However, this could cause some flickering if the tcomp
varied significantly from frame to frame.
The timer classes discussed in Chapter
8: Tech : Timers help considerably with program timing. In particular,
class, which became available in Java 1.3, provides the scheduleAtFixedRate()
method. The two overloaded versions fix the timing events relative
to the clock rather than by delay from the previous event as with
method. In the latter case, timing errors would accumulate relative
to the clock.
We will compare the timing methods in the following applet. It
does a animation of a ball falling and then bouncing until it comes