Introduction
Threads Overview
  Demo 1   Demo 2
Stopping Threads
Multi-Processing
Thread Tasks
Animations
  Demo 3   Demo 4  
  Demo 5
Non-interacting
  Demo 6
Task Splitting
  Demo 7
Exclusivity
  Demo 8
Communicating
  Demo 9
Priority/Scheduling
More Thread
Exercises

    Supplements
Java2D Animation
  Demo 1 
Processor View
More Concurrency
Cloning
  Demo 2  Demo 3 

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:

• t_clock - this will be an increment in the actual clock time in the world of the person running the simulation and on the processor clock.
  
  
• t_sim - this is the time increment represented by the simulation. For example, in a simulation of a planetary orbit, t_sim might represent a day or a week. In a simulation of an atomic interaction, on the other hand, t_sim might represent a nanosecond or less.
  
  
• dt_calc - the time increment used in a numerical calculation of the simulated phenomena over the time span of t_sim. To obtain an accurate simulation, dt_calc must often be much smaller than t_sim.. For example, in the case of a ODE
      dt_calc = t_sim/N
  for N steps in the integration.

If we attempt to match t_sim to the t_clock time, we will say t_sim 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:

• t_frame - the time between frames, such as 40 msecs to provide 25 frames per second.
• t_comp - 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 t_comp could vary from frame to frame.
• t_display - the time it takes to display the frame.
• t_sleep - the idle time between when the frame display and the start of the next frame calculation.
• t_interrupt - 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 time increments.

Before Java 1.2, animations required using the Thread class sleep() method (see Chapter 8: Java : Demo 1) to pause between the calculation and display processing. However, this could cause some flickering if the t_comp varied significantly from frame to frame.

The timer classes discussed in Chapter 8: Tech : Timers help considerably with program timing. In particular, the java.util.Timer 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 the schedule() 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 to rest.

              Tech
Timers
  Demo 1
Hist. Adapt Range
  Demo 2
Sorting in Java
  Demo 3
Histogram Median
  Demo 4
Refactoring
  Demo 5
Error Bars
  Demo 6
Exercises

           Physics
Least Squares Fit
  Demo 1
Fit to Polynomial
  Demo 2
Fit Hist Errors
  Demo 3
Discretization
  Demo 4
Timing
  Demo 5
Exercises