Implementation Notes
There are a few issues about the implementation of this applet that merit some comment.
The first issue is the selection of an actual development system. Why develop in Java vs another, easier to use system such as Matlab. This is a question that has plagued the program developers of the Computer Enhanced Education group at the Georgia Instutute of Technology.
There are some inherent advantages to using a system like Matlab. Matlab is extreamly easy to program in and use. Further, the multitude of Matlab toolboxes allows programmers to choose from a warchest of prewritten functions to accomplish teadious tasks such as matrix multiplication and solution of differential equations. These tools enable quick and effective development. However, since Matlab is primarly a calculation tool, it has limited and perhaps clumsy infrastructure for making user interfaces.
Java's primary advantage, of course, is the ease of which a developer can place their program on the World Wide Web. Further, Java has the maturity of being a full fledged programming language. With the development of IDE/GUI programming tools for Java, user interfaces and graphics is very easy and the developer has full control over the display of these items.
One drawback of Java is that it is quite a young development tool and thus does not have the welth of preprogrammed functions like Matlab. Some times the Java developer may feel like they are starting from the ground up.
One distinct advantage that Java has over Matlab is its ability to implement threads. This is expanded upon below.
What is a thread?? A thread is a length of code in a program that can operate independantly from the rest of the code in that program. This means that more than one "process" could be operating simultaniously (sort of ) and independantly of each other.
This feature could be very useful in the demonstration of particular systems. For example, suppose that the concept of diffusion is to be illustrated. A programmer creates a rectangle, representing a tube, that contains 20 circles clustered at one end. These circles represent particles.
With out the use of threads, a programmer would have to track the path of each of these particles using some kind of fast sampling looping algorithm. The tracking of the postition of each particle could perhaps be computed and each particle-particle and each particle-wall collision would have to be detected at each slice of time. This approach could be cumbersome.
With the use of threads, the programmer would only have to dictate what happens when a particle collides with another or a wall. A random set of initial velocites would be assigned to each of the 20 particles. The programmer would then start the 20 different threads running.
This scheme allows for different time scales. When no collisions are taking place, the program dosent have to "think" and when a collision does take place, it the individual threads are not concerned with the other theads running. Faster moving particles would generate many collision events requiring quite a bit of processor time and slower moving particles would perhaps generate fewer collisions and require less processor time. This programming scheme just seems to better fit this system.
Threads are used in this program in two places. The first thread is used during a calculation of a solution and the second thread is used during the playing of an animation. This means that the user can run both a simulation and animation at the same time. However, both threads will run slower. Further, since a thread can be killed, this allows for easy interruption of a process.
There are many ways to find the time domain solution of the mass spring damper system. One easy way would be to solve for a general solution by hand and keep the solution in terms of the system parameters. This would result in some complicated function that could be plotted once the system parameters were selected. However, the solution generated by this method would be limited to the mass spring damper (second order linear) system.
Another way to solve for the time domain solution of this linear system would be to implement a convolution. The convolution of the input signal with the impulse response of a linear system yields the output signal. However, convolution only makes sense for linear systems.
Since a future version of this program could involve a nonlinear system, the solver uses a numerical integration scheme known as the Runge-kutta algorithm. This requires that the system be described in terms of differential equations so that the system can be integrated to get the solution. In fact, the system is defined as a system of first order equations by what is called a State Space Representation. This is described further in the Background Theory section of these help files.
The Runge-Kutta algorithm was adapted from "Numerical Recipes for C, Second Edition". (chapter 16)