views:

66

answers:

3

I've got a table of values telling me how the signal level changes over time and I want to simulate a harmonic oscillator driven by this signal. It does not matter if the simulation is not 100% accurate. I know the frequency of the oscillator. I found lots of formulas but they all use a sine wave as driver.

+2  A: 

I guess you want to perform some time-discrete simulation. The well-known formulae require analytic input (see Green's function). If you have a table of forces at some point in time, the typical analytical formulae won't help you too much.

The idea is this: For each point in time t0, the oscillator has some given acceleration, velocity, etc. Now a force acts on it -according to the table you were given- which will change it's acceleration (F = m * a). For the next time step t1, we assume the acceleration stays at that constant, so we can apply simple Newtonian equations (v = a * dt) with dt = (t1-t0) for this time frame. Iterate until the desired range in time is simulated.

The most important parameter of this simulation is dt, that is, how fine-grained the calculation is. For example, you might want to have 10 steps per second, but that completely depends on your input parameters. What we're doing here, in essence, is an Eulerian integration of the equations.

This, of course, isn't all there is - such simulations can be quite complicated, esp. in not-so-well behaved cases where extreme accelerations, etc. In those cases you need to perform numerical sanity checks within a frame, because something 'extreme' happens in a single frame. Also some numerical integration might become necessary, e.g. the Runge-Kutta algorithm. I guess that leads to far at this point, however.

EDIT: Just after I posted this, somebody posted a comment to the original question pointing to the "Verlet Algorithm", which is basically an implementation of what I described above.

mnemosyn
Yeah, that's why I took it down. But there's issues related to the one on the MIT's page, I couldn't find a suitable variant. Might want to stick with the velocity verlet algo, but I can't find code. http://en.wikipedia.org/wiki/Verlet_integration#Velocity_Verlet
I guess that is what the OP's assignment is all about - fiddling around with the numerical deficiencies that arise and try to implement the simulation. Let's not take all the fun out of it ;) No, honestly, don't know of an implementation myself, but I guess the question is answered. Implementing it should be a separate concern.
mnemosyn
+1 - A very nice answer, indeed. I'd give it more if I could.
duffymo
A: 

Ok, i finally figured it out and wrote a gui app to test it until it worked. But my pc is not very happy with doing it 1000*44100 times per second, even without gui^^

Whatever: here is my test code (wich worked quite well):

double lastTime;  
const double deltaT = 1 / 44100.0;//length of a frame in seconds  
double rFreq;  
private void InitPendulum()  
{  
double freq = 2;//frequency in herz  
rFreq = FToRSpeed(freq);  
damp = Math.Pow(0.8, freq * deltaT);  
}  

private static double FToRSpeed(double p)  
{  
p *= 2;  
p = Math.PI * p;  
return p * p;  
}  
double damp;  
double bHeight;  
double bSpeed;  
double lastchange;  
private void timer1_Tick(object sender, EventArgs e)  
{  
  double now=sw.ElapsedTicks/(double)Stopwatch.Frequency;  
  while (lastTime+deltaT <= now)  
  {  
    bHeight += bSpeed * deltaT;  
    double prevSpeed=bSpeed;  
    bSpeed += (mouseY - bHeight) * (rFreq*deltaT);  
    bSpeed *= damp;  
    if ((bSpeed > 0) != (prevSpeed > 0))  
    {  
      Console.WriteLine(lastTime - lastchange);  
      lastchange = lastTime;  
    }  
    lastTime += deltaT;  
  }  
  Invalidate();//No, i am not using gdi^^  
}
Floste
Simulations can be *very* compute-intensive. Almost everything that all the world's supercomputers do is really just one kind of simulation or another.
Donal Fellows
well i had some errors and bottlenecks. Now it works fine with 512oscillators *44100frames/sec with 40% cpu usage but the analysis is a bit unsharp by design. (same as with fft, but fft is not very accurate at low frequencies)
Floste