With this release, the solver behavior for any model that contains tires has been updated to produce more accurate velocities and accelerations. The solver now recognizes force elements that model the tire and monitors the rotating wheel bodies so that the velocities and accelerations are computed more accurately.

For models that make use of the <Force_VectorTwoBody> modeling element to represent tires, you can expect to see smoother results slip ratio and tire rotational velocity.

Previously, MotionSolve was unable to access a Python script that was not located on the same machine as the MotionSolve installation. This issue has been fixed, now, you can run a simulation in a scenario where MotionSolve in installed on one machine and the scripts are located on another network location.

Note: you need to have read access to the network location where your scripts are located.

Previously, if your model consisted of multiple flexible bodies generated using a combination of PLOTEL and non-PLOTEL elements, the flexible bodies would not be displayed properly in HyperView. This issue has been fixed within this release.

Several issues have been fixed for the linear analysis within this release:

In the previous release, you were unable to link your user subroutine code with the MotionSolve user subroutine API library (ms_usersubapi) using the GCC compiler. Starting with this release, this restriction has been removed. Now you can use both the GCC and Intel compilers to compile and link your user subroutine code.

Previously, a gear modeled using the <Constraint_Gear> statement resulted in an incorrect gear ratio calculation in the solver. This has been fixed within this release.

The SENVAL function should return a value of 0 when the sensor it refers to is not active during the simulation; this behavior was not seen in the previous release. This has been fixed starting with this release.

If your model contains a <Sensor_Event> modeling element that is deactivated before the first <Simulate> command is executed, the simulation would crash with the previous release.

This was determined to be a bug and has been fixed with this release.

Previously, the post processing module in MotionSolve crashed if your model contained an output request that referred to a ‘0’ marker ID. This scenario may occur with older MotionSolve models. This has been fixed such that the post module simply ignores such a marker request.

Previously, if your model contained a PROXIMITY function that referred to a deactivated sensor in your model, the simulation would crash in such a scenario. This has been fixed such that the use of such a PROXIMITY function does not halt the simulation.

Note: It is important to keep track of which sensors are deactivated in your model since the PROXIMITY function referring to a deactivated sensor will return a 0 value.

Previously, if you modeled 3D rigid body contact with at least one body being a box graphic defined by a negative length, the contact force was not generated as expected. This has been fixed with this release.

Previously, if you defined a solver variable using multiple IF statements and queried the solver for this variable’s value in a Post_Request using VARVAL(..), MotionSolve did not return the exact values for the variable as defined by the user. Specifically, the values were incorrect at the points where the gradient of the expression for the solver variable is discontinuous.

This issue can be resolved by specifying dae_interpolation = “FALSE” in the <Param_Transient> model or command statement in the MotionSolve XML input file.

Markers with direction cosine matrix very close to the identity matrix were not translated correctly to the MotionSolve XML input file. This was caused by a loose numerical tolerance in MotionSolve.

Previously, for a kinematically constrained model, if you specified a motion on a joint using multiple IF statements, the velocity of the marker associated with the joint showed a difference if the model was solved using the VSTIFF or DSTIFF integrator.

This has been fixed within this release – the choice of the integrator does not matter for such a kinematic model.

Note: Use of the IF function to define motions is not recommended in MotionSolve, since the IF function tends to produce discontinuities which make it hard for the solver to converge and can produce erroneous results in certain cases. Please refer to the documentation on <Motion_Joint> for more tips on defining smooth motion inputs.

Previously, a gear modeled using the <Constraint_Gear> statement returned an incorrect gear ratio in MotionSolve. This has been fixed within this release.

Previously, a Motion defined as a saw-tooth function using a series of IF statements returned results inconsistent with the user input. This has been fixed within this release.

Previously, if your model contained multiple Simulate commands and a <Motion_Joint> modeling element was modified in between the analyses, MotionSolve did not update the <Motion_Joint> value correctly thus yielding incorrect results or simulation failure. Such a scenario is shown below:

This has been resolved with this release.

Previously, certain models that had SDF outputs defined in them failed the GTCMAT calls. This was determined to be an issue in the solver code and has been fixed with this release.

Previously, if you save and load your model that contains joint friction modelling elements, the reloaded model will not solve correctly. This has been identified as an error in writing the model upon saving.