You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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)?
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 saysetMaxTorque()could be omitted, is because it just setsLastTorque, 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 forRelaxTorqueThresholddoes not useLastTorqueat all, so this does not add to the utility ofsetMaxTorque. WhethersetMaxTorque()could be removed is therefore up for debate.