Cannot Compute Weighted Torque

[harryswift01]

Computing the weighted torques results in NaN values

[skfegan]

Looking at Argo's code again. It appears they used the logic that if the torque (not the moment of inertia) was close to zero then the torque did not need weighting. This should be fine as 0 divided by anything would still be 0.

If we add the check for zero torque before the divide by moment of inertia this might remove some of the crashes. The weighting should still check for divide by zero errors.

[skfegan]

Also we should check that the zero (or near zero) torques behave properly in the rest of the calculations.

[harryswift01]

Just made a couple of commits to reflect on what you suggested, thanks for double checking. Just to make sure everything is covered @skfegan which torque calculations should I put these guards in for?

[skfegan]

There are three cases to consider

• torque 0 ... no weighting necessary
• torque not 0 AND moment of inertia 0 or negative ... divide by zero or imaginary square root problems
• torque not 0 AND moment of inertia positive ... weighting by moment of inertia as expected

In the get_weighted_torque function of GeometricFunctions.py I think maybe it should be something like
if np.isclose(torques[dimension],0):
weighted_torque[dimension] = torques[dimension]
elif moment_of_inertia[dimension,dimension] <=0:
raise ValueError
else:
weighted_torque[dimension] = torques[dimension] / np.sqrt(moment_of_inertia[dimension, dimension]

[skfegan]

We should probably have checks any time there is a sqrt() that it is not being given a negative number, and any division should raise an error if there is a divide by zero.

There is also a filter_zero_rows_columns function (defined in GeometricFunctions.py; used in LevelFunctions.py). I don't know what it does when all the numbers in a matrix are zero? Or what we want it to do?

[harryswift01]

Thanks for clarifying further @skfegan, I think that the implementation that I linked into this issue addresses this now. In terms of the second comment I think it may potentially be out of scope for this particular issue, but I will raise another more general issue to address this to make sure that all of the calculations within CodeEntropy are guarded correctly.