OK I have uploaded the JAMA library and written two new important methods:
public static final RealPointer toODEMatrix(Jama.Matrix matrix)
AND
public static final Jama.Matrix toJAMAMatrix(RealPointer rp, int numColumns, int numRows)
The methods will allow you to switch between ODe representations of matrices and JAMA representations with relative ease. These mathods take into acount the padding used in ODE. So a 3x3 matrix which is stored as as an array of 12 elements is fine to put through these methods. The numColumns and numRows are the desired size of the output array.
With JAMA intergration I have depricated the existing Cholesky solve and factor methods and provided an alternative intergrator that uses the JAMA functionality. The old ways are still an option, but using them gives poorer, and probably incorrect results.
Now I am fairly sure the Cholesky stuff works correctly I have discovered it cannot handle friction. This is not actually a suprising result as the LCP algorithm was designed for handling friction and all the frictions stuff is packed into a funny form which I don’t think the Cholesky stuff knows how to handle. However, the cholesky stuff should be correct for unconstrained joints.
I have added two new types of joints. Ball and Hinge; they do not work. The don’t work in exactly the same was using the LCP intergrator as the Cholesky stuff. so I think there may be a problem with actually joint code. anyway there are two new tests for them in a new test package named joints.
Finally I have added a JUnit test. Low level testing is very helpful I find, but its personal style I guess. It tests the new JAMA conversion functions.
PS I consulted the ODE documentation and the JAMA documention and am fairly confident I got the packing the correct way round for both of them. There is of course a chance I did not though, so I have two additional methods toODEReversePackingMatrix and toJAMAReversePackingMatrix which have been tested for consistancy. But these should not be used.