The Wave Equation
In our previous class, we improved our time integration to use the popular fourth-order Runge-Kutta method, and now our simple spring system is looking pretty good. It would be great if we could just use RK4 for any simulation problem we might encounter, and have it just work. Let's explore a system that's a little bit more complicated.The 1D Wave Equation describes the motion of waves in a height field, and can be written simply as:
Just like in our simple spring example, we have an equation of motion in which the acceleration of position (height, in this case) is expressed as a function of the current value of position (again, height). However, we've added a complication! The function of position itself involves a second derivative of height, this time with respect to space, rather than time. The constant \(c^2\) represents the square of the wave propagation speed, and is a parameter to the system. So now we've graduated from our previous simple Ordinary Differential Equations ODE to the much more exciting Partial Differential Equations PDE.
The Wave Equation, in 1D, is extremely similar at its core to the simple spring equation, and indeed, if you explore the wikipedia article, you'll see that it is actually derived by imagining a series of masses, evenly spaced, attached to each other via springs, as seen in this illustration:
State Definition for Wave Equation
We're going to try to use our RK4 implementation from the spring example directly, so we'll need to create space in the state vector for the temporary values created. RK4 sets its final estimate to a weighted average of the four estimates it creates along the way, and each estimate is created from the previous estimate. Therefore, rather than storing all four estimates separately, we can accumulate each estimate directly into our final sum. Here's what our state will look like:
int StateSize = 7;
float[][] State = new float[StateSize][ArraySize];
int StateHeight = 0;
int StateVel = 1;
int StateHeightPrev = 2;
int StateVelPrev = 3;
int StateVelStar = 4;
int StateAccelStar = 5;
int StateHeightTmp = 6;
Initial State
The initial state of the wave equation example is a bit more complex than the pendulum or the spring. For this example, we're going to use several octaves of perlin noise to create a wave-like distribution of crests. Because our initial state is complex and large, we don't want to keep a copy of it around. If we need to reset, we'll simply call the SetInitialState function that we create. Here's that function, which is entirely subject to artistic interpretation:
void SetInitialState()
{
noiseSeed( 0 );
for ( int i = 0; i < ArraySize; ++i )
{
float worldX = 2341.17 + DX * ( float )i;
State[StateHeight][i] = 0.5 * anoise( worldX * 0.0625 ) +
0.4 * anoise( worldX * 0.125 ) +
0.3 * anoise( worldX * 0.25 ) +
0.2 * anoise( worldX * 0.5 );
State[StateVel][i] = 0.0;
}
EnforceBoundaryConditions( StateHeight );
EnforceBoundaryConditions( StateVel );
StateCurrentTime = 0.0;
}
Boundary Conditions
In order to compute the second derivative of height, spatially, we need to reference values at adjacent points to the left and right. When we reach the sides of the simulation, though, we have a problem - what value do we use when we're looking off the side of the simulation? For these areas, the simulation needs to have an answer without actually storing a state. The areas of the simulation where we already know the answer, or some aspect of the answer, are called Boundary Conditions. The area of the simulation where boundary conditions are applied is called, not surprisingly, the boundary. The boundary in our simulation is the edges of the wave to the left and right, but if we were to have collision objects, for example, the places where the simulation met the collision objects would be considered a boundary also.There are many different types of boundary conditions, which place varyingly subtle constraints on the values at boundary points. In this simple wave equation simulation, we're going to assert that the values at the boundary are exactly equal to the simulated values just adjacent to the boundary. In other words, we are asserting that the derivative of any value across the boundary is zero. This explicit constraint on a derivative of a value is called a Neumann Boundary Condition. We implement it in code very simply, by just copying the values to the edges:
void EnforceBoundaryConditions( int io_a )
{
State[io_a][0] = State[io_a][1];
State[io_a][ArraySize-1] = State[io_a][ArraySize-2];
}
Note that in this implementation, we allow ourselves to affect any part of the state vector. The flexibility of our abstract state field naming again shows its power!
Integration Tools
In the simple spring example, we were able to simply create temporary floats to store temporary values, and we were able to use arithmetic operators to compute the integrated fields. Because our state values are now arrays of data, we need special functions for evaluating equations over the whole array at once. These are called "vectorized" functions. Let's break them down one by one. First, a utility function for copying an array from one part of the state vector to another:
void CopyArray( int i_src, int o_dst )
{
for ( int i = 0; i < ArraySize; ++i )
{
State[o_dst][i] = State[i_src][i];
}
}
As we move from time step to time step, we need to swap out our "current" height and velocity values into a "previous" array. Because of the way we've indexed our state vector with labels, we don't have to actually copy the values over. You could imagine that in a very large fluid simulation, this copying of millions of points of data would be very expensive. Instead, we just swap the labels:
void SwapHeight()
{
int tmp = StateHeight;
StateHeight = StateHeightPrev;
StateHeightPrev = tmp;
}
void SwapVel()
{
int tmp = StateVel;
StateVel = StateVelPrev;
StateVelPrev = tmp;
}
void SwapState()
{
SwapHeight();
SwapVel();
}
The RK4 technique involves, for every estimate other than the first, estimating a temporary value for height using the vStar estimate from the previous estimation iteration, and the height of the previous time step. The time interval over which these temporary height estimates are made varies from iteration to iteration. This function is simple! In our spring example, it looked like this:
float xTmp = State[StatePositionX] + ( i_dt * vStar1 );
In our wave state, this operation on a single float gets expanded to work on the whole state array like so:
// Estimate temp height
void EstimateTempHeight( float i_dt )
{
for ( int i = 0; i < ArraySize; ++i )
{
State[StateHeightTmp][i] = State[StateHeightPrev][i] +
( i_dt * State[StateVelStar][i] );
}
EnforceBoundaryConditions( StateHeightTmp );
}
Following along, in the simple spring example we then had to estimate a new velocity, vStar based on the previous iteration's aStar, and the previous time step's velocity. In the spring example, that looks like this:
float vStar2 = State[StateVelocityX] + ( i_dt * aStar1 );
In our wave state, this operation is expanded as follows:
// Estimate vel star
void EstimateVelStar( float i_dt )
{
for ( int i = 0; i < ArraySize; ++i )
{
State[StateVelStar][i] = State[StateVelPrev][i] +
( i_dt * State[StateAccelStar][i] );
}
EnforceBoundaryConditions( StateVelStar );
}
Discretizing the Spatial Derivative of Height
Finally, we need to port the computation of acceleration from an estimated position. In the spring example, this was as simple as could be (on purpose):
// Acceleration from Position.
float A_from_X( float i_x )
{
return -( Stiffness / BobMass ) * i_x;
}
Now that we have a spatial derivative in our setup, though, we need to calculate
our acceleration based not only on the position at each point in the grid,
but also the neighboring points in the grid. In order to do that, we need
to discretize the second spatial spatial derivative, which we can do using
finite differences, as we learned several classes ago. The finite difference
approximation to the second derivative, in one dimension, looks like this:
Which simplifies to:
We can implement this in code as follows:
void A_from_H( int i_h )
{
for ( int i = 1; i < ArraySize-1; ++i )
{
float hLeft = State[i_h][i-1];
float hCen = State[i_h][i];
float hRight = State[i_h][i+1];
float d2h_dx2 = ( hRight + hLeft - ( 2.0*hCen ) ) / sq( DX );
State[StateAccelStar][i] = sq( WaveSpeed ) * d2h_dx2;
}
EnforceBoundaryConditions( StateAccelStar );
}
Note that we only iterate across the center values in the arrays - we skip the very first and the very last points, because they don't have values adjacent to themselves in one direction. Here is where the boundary conditions help to fill in the gaps, and you can see that they're applied at the last step.
The Time Step
Okay, so armed with all the pieces above, we can construct our TimeStep. It should look just like the spring solver's RK4 time-step, with the appropriate adjustments for the array data. Here was the old time step:
// Time Step function.
void TimeStep( float i_dt )
{
float vStar1 = State[StateVelocityX];
float aStar1 = A_from_X( State[StatePositionX] );
float vStar2 = State[StateVelocityX] + ( ( i_dt / 2.0 ) * aStar1 );
float xTmp2 = State[StatePositionX] + ( ( i_dt / 2.0 ) * vStar1 );
float aStar2 = A_from_X( xTmp2 );
float vStar3 = State[StateVelocityX] + ( ( i_dt / 2.0 ) * aStar2 );
float xTmp3 = State[StatePositionX] + ( ( i_dt / 2.0 ) * vStar2 );
float aStar3 = A_from_X( xTmp3 );
float vStar4 = State[StateVelocityX] + ( i_dt * aStar3 );
float xTmp4 = State[StatePositionX] + ( i_dt * vStar3 );
float aStar4 = A_from_X( xTmp4 );
State[StatePositionX] += ( i_dt / 6.0 ) *
( vStar1 + (2.0*vStar2) + (2.0*vStar3) + vStar4 );
State[StateVelocityX] += ( i_dt / 6.0 ) *
( aStar1 + (2.0*aStar2) + (2.0*aStar3) + aStar4 );
// Update current time.
State[StateCurrentTime] += i_dt;
}
And here's the new one, for the wave system:
// Time Step function.
void TimeStep( float i_dt )
{
// Swap state
SwapState();
// Initialize estimate. This just amounts to copying
// The previous values into the current values.
CopyArray( StateHeightPrev, StateHeight );
CopyArray( StateVelPrev, StateVel );
// Vstar1, Astar1
CopyArray( StateVel, StateVelStar );
A_from_H( StateHeight );
// Accumulate
AccumulateEstimate( i_dt / 6.0 );
// Height Temp 2
EstimateTempHeight( i_dt / 2.0 );
// Vstar2, Astar2
EstimateVelStar( i_dt / 2.0 );
A_from_H( StateHeightTmp );
// Accumulate
AccumulateEstimate( i_dt / 3.0 );
// Height Temp 3
EstimateTempHeight( i_dt / 2.0 );
// Vstar3, Astar3
EstimateVelStar( i_dt / 2.0 );
A_from_H( StateHeightTmp );
// Accumulate
AccumulateEstimate( i_dt / 3.0 );
// Height Temp 4
EstimateTempHeight( i_dt );
// Vstar3, Astar3
EstimateVelStar( i_dt );
A_from_H( StateHeightTmp );
// Accumulate
AccumulateEstimate( i_dt / 6.0 );
// Final boundary conditions on height and vel
EnforceBoundaryConditions( StateHeight );
EnforceBoundaryConditions( StateVel );
// Update current time.
StateCurrentTime += i_dt;
}
It's a little bit longer in code length, but importantly - it doesn't actually contain more operations! If you compare this to the previous example, you'll see that it's basically the same! Let's see what that looks like running in processing with it all added together:
That's not bad! Perhaps we could make it more interesting, by gathering some mouse input. We'll make it so that if you click in the view, it will set the height and velocity of the sim at that point to the height of the click, and zero, respectively. The input grabbing code looks like this:
void GetInput()
{
if ( mousePressed && mouseButton == LEFT )
{
float mouseCellX = mouseX / ( ( float )PixelsPerCell );
float mouseCellY = ( (height/2) - mouseY ) / ( ( float )PixelsPerCell );
float simY = mouseCellY * DX;
int iX = ( int )floor( mouseCellX + 0.5 );
if ( iX > 0 && iX < ArraySize-1 )
{
State[StateHeight][iX] = simY;
State[StateVel][iX] = 0.0;
}
}
}
And we just add that directly into our main draw loop, right before the time step:
void draw()
{
background( 0.9 );
GetInput();
TimeStep( 1.0 / 24.0 );
// Label.
fill( 1.0 );
text( "Wave Equation RK4", 10, 30 );
DrawState();
}
And what happens now? Here it is running:
Uh oh.... Looks like stability has eluded us again. Next class, we'll look into how to fix stability for cases like this, involving multiple derivatives.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.