"real time" non-linear oscillators using GSL

Hello all, I really hope someone can help me with this as I’m not getting anywhere…

So firstly, I am using the GNU Scientific Library to make a Van der Pol oscillator. That all works as a stand alone class which I’ve named gsl_vdpo (see attached header and source files). I’ve followed the second example from here: http://www.gnu.org/software/gsl/manual/html-node/ODE-Example-programs.html and as far as I can tell in independant tests (i.e., not in OF) it works great.

Now the idea is that I can have an oscillator running in “real time” by integrating it with OF and getting it to update itself on the testApp::update step. (Again, see the attached testApp header and source files). The big problem is that I run into a segmentation fault whenever I try to use gsl_vdpo::advance_to in testApp::update. Using it in testApp::setup, though is absolutely fine.

Things to note:
At the moment I’m working in Linux.
gsl_vdpo works independently, but I have not tried it in a threaded environment.
I have tried using ofxThread to see if that is the issue, but still no joy.

If anyone can help, it would be much appreciated!

Code attached.





not sure why it’s crashing, 2 things that seems wrong though:

you cannot initialize an array after declaring it like:

y = { 1.0, 0.0 };  

you are probably getting a warning like, initializer lists are only allowed in c++0x, that’s because that syntax will be legal in the next c++ standard but not now. don’t know what the results of doing that can be though.

also the way you are calculating the step like:

double step = 1/ofGetFrameRate();  

is not very precise, you can use better:

double step = ofGetLastFrameTime();  

Thanks for your quick reply Arturo,

I didn’t know about ofGetLastFrameTime(), very useful :slight_smile:

Interesting about the array initialisation too, inspecting the variable after initialisation shows it’s working fine, so that’s not the issue either.

Hmm… the search continues.


I also think it may have something to do with the way you are initializing some of the data in your gsl_vdpo copnstructor. I’m having a hard time finding out if this is true, but I THINK that the way you’re doing this:

gsl_odeiv2_system s = {step, jacobian, 2, &damping};  
system = &s;  

is dangerous.
I’m pretty sure that the variable s, which I’m guessing is a struct of some sort, will be deallocated after the constructor returns. Maybe the reason you can’t run the system outside of testApp::setup() is that something else that is critical took the place of that memory address, which is being remembered by the system pointer.

Tims right, that’s not going to be around as soon as that method exits. You’re saying that ‘system’ is going to point to something on the stack that’ll be destroyed as soon as the method exits. I’m not sure how gsl_odeiv2_system is set up, but it seems like it’s just a struct so you’d want to do:

system s = new gsl_odeiv2_system;  
s.step = step;  
s.jacobian = jacobian;  
s.whatever =  2;  
s.damping = &damping;  


Thanks so much Tim and Joshua, it works!

I knew it would be something silly like that - I’m still not completely au fait with cpp compared to Java.

Thanks again!