Computing Changes in the Simulation State
Now that we've defined the simulation state in the previous class, and made
an effort to make sure we can display our simulation state, it's time to get
to the interesting bit : simulating a change in the system over time. Note
that not all simulations involve change over time - for example the calculation
of material stress in a crane supporting a heavy weight. But, for our purposes,
we'll focus on examples that involve matter moving in time.
A Simple Spring System
In order to evaluate the behavior of different motion simulation techniques,
we need to work with a system that has an exact solution that we can easily
calculate, so we can compare our simulation results to the theoretical
correct results. A mass connected to a spring, with the spring initially
stretched out, provides such a system. We'll create a state and draw routine
that looks very similar to the simple the pendulum state from the previous
class. We have a stiffness for the spring and a mass for the weight at the
end of the string as configuration parameters. We restrict the mass
to only move left and right, so we only store positions and velocities
in the X dimension.
float Stiffness = 5.0;
float BobMass = 0.5;
int StateSize = 3;
float[] InitState = new float[StateSize];
float[] State = new float[StateSize];
int StateCurrentTime = 0;
int StatePositionX = 1;
int StateVelocityX = 2;
int WindowWidthHeight = 300;
float WorldSize = 2.0;
float PixelsPerMeter;
float OriginPixelsX;
float OriginPixelsY;
void setup()
{
// Create initial state.
InitState[StateCurrentTime] = 0.0;
InitState[StatePositionX] = 0.65;
InitState[StateVelocityX] = 0.0;
// Copy initial state to current state.
// notice that this does not need to know what the meaning of the
// state elements is, and would work regardless of the state's size.
for ( int i = 0; i < StateSize; ++i )
{
State[i] = InitState[i];
}
// Set up normalized colors.
colorMode( RGB, 1.0 );
// Set up the stroke color and width.
stroke( 0.0 );
//strokeWeight( 0.01 );
// Create the window size, set up the transformation variables.
size( WindowWidthHeight, WindowWidthHeight );
PixelsPerMeter = (( float )WindowWidthHeight ) / WorldSize;
OriginPixelsX = 0.5 * ( float )WindowWidthHeight;
OriginPixelsY = 0.5 * ( float )WindowWidthHeight;
}
// Draw our State, with the unfortunate units conversion.
void DrawState()
{
// Compute end of arm.
float SpringEndX = PixelsPerMeter * State[StatePositionX];
// Draw the spring.
strokeWeight( 1.0 );
line( 0.0, 0.0, SpringEndX, 0.0 );
// Draw the spring pivot
fill( 0.0 );
ellipse( 0.0, 0.0,
PixelsPerMeter * 0.03,
PixelsPerMeter * 0.03 );
// Draw the spring bob
fill( 1.0, 0.0, 0.0 );
ellipse( SpringEndX, 0.0,
PixelsPerMeter * 0.1,
PixelsPerMeter * 0.1 );
}
// Processing Draw function, called every time the screen refreshes.
void draw()
{
background( 0.75 );
// Translate to the origin.
translate( OriginPixelsX, OriginPixelsY );
// Draw the simulation
DrawState();
}
Here's what that looks running in Processing - this, again, is just a repeat of
the previous class's state initialization and drawing ideas, extended a little
to include the notion of an initial state as separate from the state itself.
Motion of a Simple Spring
The equation of motion for a simple spring is, um, simple:
\(
F = -k x
\)
Where F is force, k is a constant representing the stiffness of the spring, and
x is the position of the mass. This simple system is known as a
Harmonic Oscillator
. As we almost always do in physics, unless we're
those weird quantum folks, we consult
Newton's Laws of Motion, specifically the second one, which as the
world's second most famous equation, says:
\(
F = m a
\)
Where F again, is force, m is mass, in this case the mass of the object at
the end of our simple spring, and a is the acceleration of the object. By
definition, acceleration is the rate of change of velocity over time, and
velocity is the rate of change of position over time. In this simple system,
that can be expressed in the following way, using derivatives:
\(
v = \frac{dx}{dt} \\
a = \frac{dv}{dt} = \frac{d^2 x}{dt^2}
\)
We often use the prime and double-prime notation as a shorthand for
differentiation by time, which looks like this:
\(
v = x' \\
a = v' = x''
\)
Using the equations above, and substituting for acceleration, the simple
spring equation becomes:
\(
x'' = \frac{-k}{m} x
\)
What we see here is what is known as an
Ordinary Differential Equation, or
ODE for short.
ODE's are
equations which relate a variable (in our case the position, x), to one
or more derivatives of that variable with respect to a single other variable,
(in our case time, t).
Most simulations of motion are numerical approximations of
ODE's, or
more commonly,
Partial Differential Equations, in which multiple quantities will be
equated to the partial derivatives of those quantities with respect to
multiple other quantities, not just time. We call those
PDE's for short,
of course.
This equation expresses a relationship that holds true at any moment in time,
and in this very simple case, there actually is an exact solution to the
equation as a calculable function of time t, given an initial condition of
position = x0 and velocity = v0:
\(
x(0) = x_0 \\
x'(0) = v(0) = v_0 \\
x(t) = x_0 \cos( \sqrt{ \frac{k}{m} } t ) +
\frac{v_0}{\sqrt{\frac{k}{m}}}
\sin( \sqrt{ \frac{k}{m} } t )
\)
We chose this simple case precisely because it did have an exact solution that
we will be able to use to compare our simulation results to. However, it is
not usually true that there is an explicit, closed-form equation of time
like the one above that can be simply evaluated for the solution to the
system at any given time. For example, the equation for the angular acceleration
of the pendulum from our previous class is:
\(
\theta'' = -\frac{g}{L} \sin( \theta )
\)
This equation does not have a simple solution, and that will be true for
anything interesting enough to bother simulating.
Therefore, in order
to calculate the position of the pendulum at some specific time Tk, we'll have
to start at our initial time T0, and slowly iterate the solution forward
through small, discrete increments of time, with each new time's solution being
based on the previous time's solution. These time increments are usually
very small. In the film world we work in 24 frames per second (or
25, or 30, or 48, or 60...), and simulations often require smaller steps in
order to compute good results that are stable
(a concept we'll explore more later).
Numerical Solutions to Differential Equations
The general idea of solving differential equations by evaluating approximations
to the equations on discrete points is generally called
Numerical Integration. The family of solution strategies that fall
into this category rely on a linear approximation to derivatives and partial
derivatives called a
Finite Difference
Equation.
Suppose we have a function of time, \(f(t)\). We can approximate the value of
the derivative \(f'(t)\) in the following manner:
\(
f'(t) \approx \frac{f(t+\Delta t) - f(t)}{\Delta t}
\)
Suppose, as in a case like ours, we have an expression that we can evaluate
for a derivative, but we cannot evaluate the function directly. (This is the
general problem of dynamic simulation). We can rearrange the equation above
so that we have an expression for the function at the new time, written in
terms of the values at the current time:
\(
f(t+\Delta t) \approx f(t) + \Delta t f'(t)
\)
Assuming we know the value at just one single time t0,
for the function f, the "initial value", we can use the equation above to
find the next value, and then the next, and so on, like so:
\(
f(t_0) = f_0 \\
f(t_0+\Delta t) = f_0 + \Delta t f'(t_0) \\
f(t_0+2\Delta t) = f(t_0+\Delta t) + \Delta t f'(t_0 + \Delta t) \\
...
\)
This approximation technique is called
The Euler Method, or sometimes Forward Euler, because the derivative
in the original expression was calculated from a point forward in time.
We can apply it to our spring problem by applying
it twice, since we have a second derivative. First, we calculate our acceleration
from our current position, which we can do from the simple spring equation
of motion we broke down above. Then, we update our position based on our
current velocity, and finally we update our velocity based on the acceleration
we calculated.
\(
a(t) = \frac{-k}{m} x(t) \\
x(t+\Delta t) \approx x(t) + \Delta t\ v(t) \\
v(t+\Delta t) \approx v(t) + \Delta t\ a(t)
\)
That's all we need to calculate new positions, so let's give it a try in
our code.
Adding a Time Step to our Sim Code
Let's make a few small code additions to support time integration. Below
the DrawState function, we'll add a new function called TimeStep, which will
make the calculations above, and will also set the current time, based on
a time increment DT. DT is a code-friendly way of writing \(\Delta t\), and
is common practice.
// Time Step function.
void TimeStep( float i_dt )
{
// Compute acceleration from current position.
float A = ( -Stiffness / BobMass ) * State[StatePositionX];
// Update position based on current velocity.
State[StatePositionX] += i_dt * State[StateVelocityX];
// Update velocity based on acceleration.
State[StateVelocityX] += i_dt * A;
// Update current time.
State[StateCurrentTime] += i_dt;
}
Then, we simply update our draw function to call the TimeStep function right
as it begins. We assume that each draw refresh is a single frame of time
integration, which we'll call 1/24 of a second. Here's the new draw function:
void draw()
{
// Time Step.
TimeStep( 1.0/24.0 );
// Clear the display to a constant color.
background( 0.75 );
// Translate to the origin.
translate( OriginPixelsX, OriginPixelsY );
// Draw the simulation
DrawState();
}
And that's it! Here's the whole thing, now with motion!
Hey, we've got oscillating motion! But wait.... what the hell? Why is the ball
shooting off the screen? Why is it getting faster and faster? Our sim is
unstable! We're going to need a better approximation, because as it turns out,
Forward Euler approximations are unconditionally unstable - meaning they
will ALWAYS blow up sooner or later, unless the results are manipulated.
That's the subject of our next class!
Download
All of the files associated with this class are available via a public github repository, found here:
https://github.com/blackencino/SimClass
