In RK56: remove unnecessary torque evaluation

[JonathanMaes]

In the RK56 solver, the torque was evaluated after the 9th stage. However, this torque was only used in setMaxTorque() a bit further in that function. By removing this unnecessary torque evaluation, the RK56 solver is >10% faster.

The following was not yet implemented, but is related: an additional performance gain could be achieved by not calling setMaxTorque() at all. It is not the cheapest function to calculate, and from a quick test it seems that not calling it would result in another ~5% improvement. The reason I say setMaxTorque() could be omitted, is because it just sets LastTorque, and it seems that that parameter is only used to show the maxTorque in the GUI, as well as being used in the Euler solver to determine its adaptive time step. The calculation of the maximum torque for RelaxTorqueThreshold does not use LastTorque at all, so this does not add to the utility of setMaxTorque. Whether setMaxTorque() could be removed is therefore up for debate.

[jplauzie]

Would this effect if you want to use Maxtorque as a condition in Runwhile()? For instance Runwhile( MaxTorque >1e-4) as in the standard problem 4 implementation (and a few other tests)?

[JonathanMaes]

Thanks for your comment as always, I didn't think of that related function because apparently it is completely separate in the source code.

The MaxTorque that is exposed to the user in .mx3 scripts is calculated on-the-fly the moment it is reached in the input script. It's actually an alias for the internal function GetMaxTorque(), which determines the maximum of the Torque vector field (which is also exposed to the user, and which is similarly calculated at runtime whenever required).

I sense some optimization might be possible here, either by calculating the GUI maxTorque on-the-fly, or the other way around by making MaxTorque use the LastTorque. I suspect the latter could break some code, so that might not be the way to go.