Now that we have a simulator of the physics phenomena
of interest (the dropping of a mass in a constant gravitational
field), we want to add a a detector module to the program to simulate
This kind of gravitational acceleration experiment is common in
introductory physics courses. It is done by measuring changes in
velocity of a dropped mass usually with a spark chart or photodiode
setup. Here we simulate the latter type of experiment that measures
when when the ball crosses fixed positions. Knowing the times and
the positions along the path of the ball, we can calculate its change
in velocity to obtain a measurement of g.
To insert our detector simulator into the code, we use a
- new version of the applet/app class that assembles the program
modules, including a detector.
- the detector object that simulates the measurement of the crossing
times at points along the drop track.
- A new version of the physics model so that it now invokes a
method in the detector class for each step of the ball.
- A new version of the animation display that allows the detector
to "draw itself".
The simulator page shows the code. Figure
9.3 below shows the modifications to the process for the drop simulation
combined with a detector:
Figure Phy.9.3: Similar sequence as in Figure
Phy.9.2 but with the DropDetector
class added. For each step in the simulation of the fall
the detector object is called and it notes the times when
the ball touches the marker lines. The detector also paints
itself on the animation frame. When the drop finishes, the
applet gets the data for the time of the marker crosses,
calculates the velocity for the two pairs of markers, and
then uses the change in velocity to calculate the acceleration.
Note that for the detector we make one of those design decisions
that affects the simulation's realism. For the sake of simplicity
and program performance (i.e. to insure that it can complete the
calculations within the animation frame time), we don't do a detailed
simulation of the ball's shadowing of a beam of light on the sensor.
We also don't simulate the signal from the sensor and its variations
in crossing a threshold value to trigger the time setting. Instead,
we just smear the time value according to a Gaussian distribution
with a fixed standard deviation (e.g. SD=100ms.)
Furthermore, we just pick an arbitarary smearing. For a real experiment,
you would look at the data from the detector to determine first
if the measured values do in fact follow a Gaussian distribution
and, if so, to adjust the simulation's SD
to match what it produces.
You will also see that even for this simple physics
simulation, there are some subtleties that arise. The program calculates
increments in the dropped ball's position for increments in time.
The detector measures when the ball crosses particular vertical
coordinates. If we used a fixed increment dT
for each step in the simulation (we will do this in the next
section), then as the velocity increased the distance traveled
within the DT
period would increase. So our precision in marking when the ball
passed the detector beams would grow increasingly worse as one examined
longer drops. (The program just checks whether the position has
reached or passed the detector lines for each increment.)
Here we try to fix this problem in two ways. Firstly,
we divide the animation frame times into finer steps in time. (Note
that more complex differential equations will almost always require
finer integration stepsizes than the animation frame time for accurate
results.) Secondly, we make the width of these fine time increments
inversely proportional to the velocity, so that the precision in
distance determinations remains roughly the same as the velocity
Most recent update: Oct. 25, 2005