Optimizing time spent on numerically solving ODEs?

[ijustlovemath]

I'm numerically solving an ODE with the RK4 VI. I need to use a fixed step size as I need to log values synchronously. Running one time step right now takes about 5ms on average. I ran the same ODE under Mathematica and got .2ms for the same timestep. Are are better numerical solvers out there that I could use?

[Blokk]

Hmm, maybe you could share your benchmarking code, maybe the benchmarking is not proper (or some VI settings, like debugging, etc.)? There are users in the forum who are pro in this, so you might get some good hints...

[tst]

I have no experience with it, but I believe GPower have some math tools on the tools network which might work.

[ijustlovemath]

The vi I'm timing is simply the RK4 vi from the ODE palette, with a "MeanPtByPt" attached to the ticks output. No debugging is enabled.

[Henrik_Volkers]

---

@ijustlovemath wrote:
The vi I'm timing is simply the RK4 vi from the ODE palette, with a "MeanPtByPt" attached to the ticks output. No debugging is enabled.

---

well, usually in LabVIEW you need to manually DISABLE the debugging 😉

And also usually the way how to call a (RK in this case) subvi affects the execution speed. Not all effects are obvious for moderate programmers.

[ijustlovemath]

Are you referring to reentrancy by "the way you call"? If not, mind explaining? Also, yes, debugging has been manually disabled for this VI.

[Henrik_Volkers]

No, not reentrancy... 

There are some tricks explained in some KB articles ..   You can run the ODE solver in his own thread using certain processors only dedicated to this thread, but if you, for example, call it in the UI-thread most of the performance is lost...   

Some ODEs can be reformulated to optimize execution.. some reformulation might be done in background anyway  on every call of the vi..

The solver parameters affect the speed.  Even if it outputs only the points you request, the internal stepsize can/will vary, With a very stiff ODE small changes here can make big differences 🙂 

We don't know how you call your solver. Maybe not the solver is the problem, maybe it's the rest of the loop/vi .. Can you break down your vi to the solving part only and still have the speed problem?

Sorry, very generic answers, but your problem is still very generic for us.. 

[ijustlovemath]

Yes, like I mentioned in the top post, the timing is only of the rk4 VI. I don't use a variable step size as I need points every x "minutes". Here's the VI in question: https://zone.ni.com/reference/en-XX/help/371361J-01/gmath/ode_runge_kutta_4th_order/

It takes this VI an average of 5ms (the ticks indicator) to run. So you think I should put it in its own thread and just queue up commands?

[ijustlovemath]

The calling VI:

I can't post the full code, as it's an OOP project and doing "duplicate hierarchy" wants to literally duplicate the entire project, much of which I can't share.

Here's the internals of that RK4 VI, which I'm timing at 5ms to run:

That rw/cl VI is simply an index array, meant to extract the final solutions for the timestep:

Just to be absolutely clear, it is *only* the RK4 VI that takes 5ms. The entire rest of the upper level VI averages about .34ms, which is acceptable for what it's doing.

[johnsold]

After looking at the RK VI, I suspect that you can speed some things up.

Because it uses strings for the equations and variable names and string parsing can be slow, I would look to see if you can take advantage of your knowledge of the equations you want to solve to try to eliminate that parsing from each call. There is a formula node in the body of the VI which might be faster if replaced by LV primitives. It might be possible to eliminate that for loop also. Some speed testing would be in order.

Similarly Runge Kutta Function.vi is called 4 times for each call of RK4 and it does some string manipulation that does not need to be repeated.

Can you post your equations, some typical data, and what you expect the solutions to be for that set?

Lynn