Model and Simulation Tips

General Guidelines

Start with a very simple model and add complexity step-by-step.
Run your model at each step and check whether the results make sense. Do not wait to finish the entire model before running. Debugging complex models is usually a very difficult task.

Modeling Rigid Parts

Avoid using physically unrealistic masses and inertias for the bodies in your models. For instance, the following properties are common defaults for mass and inertia: (1)
$M=1Kg, I n e r t i a = [\begin{array}{l} 1 0 0 \\ 0 1 0 \\ 0 0 1 \end{array}] {Kg-mm}^{2}$

Assuming a spherically shaped body, this mass and inertia implies a density of about 7,000 times that of steel, which is physically unrealistic. It usually slows down the solver and may even lead to simulation failure. A much better default would be:(2)
$M=1Kg, I n e r t i a = [\begin{array}{l} 1000 0 0 \\ 0 1000 0 \\ 0 0 1000 \end{array}] {Kg-mm}^{2}$
Use the Point_Mass element where applicable to reduce the degrees of freedom in your model. This element adds only three degrees of freedom to your model, whereas the rigid body element adds six degrees of freedom.
It is OK to use a dummy body with zero mass when the body is attached to another rigid and/or flexible body by a fixed joint.

Modeling Force Elements

Avoid using undamped bushings and springs. They are physically unrealistic. Undamped bushings and springs cause the solver to slow down by requiring it to track small, undamped oscillations which do not dissipate. Such oscillations are often not of interest in a simulation. Consider adding a small damping to all bushings and springs. A good starting point is 1% of the stiffness value. In many cases, such small damping is sufficient to speed up the simulation.
Avoid using the impact function with zero damping for the same reason as above.
Avoid discontinuous forces defined using the IF-function. Discontinuities may cause integrator failure. If you must use such elements, try reducing the maximum step size (H_MAX) integrator parameter in case of simulation failure.
Bushing elements are allowed to have large, angular deflections only about one axis of rotation. When they have large angular deflections about more than one axis, the results may be incorrect.

Modeling Constraints

Avoid redundant constraints

Use joint primitives to precisely impose only the necessary constraints and avoid introducing redundant ones. This may require much thought in case of complex mechanisms.
If the above step is not feasible, then consider using flexible bodies. Flexible bodies add degrees of freedom to your model and reduce the likelihood of a redundant constraint. They may also provide more accurate results.

Defining Motion Constraints in Dynamic Simulation Models

Differentiation tends to amplify any noise in the input signal. It is therefore important to ensure that all expressions and experimental data provided as input be smooth and twice differentiable. Avoid the AKIMA() interpolation method when interpolating through experimental data. AKIMA() does not calculate good first and second derivatives. Use CUBSPL() instead.
Integration tends to decrease the noise in an input signal. Therefore, it is a good idea to use velocity inputs when providing interpolated experimental or tabular data as motion input expressions.
Define your curve with as few points as possible. An excessively large number of interpolation points in a cubic curve make the first derivative "jumpy", and the second derivative "extremely jumpy", even though the curve itself may look smooth.
Make sure that the initial velocity of the motion matches the initial velocities of the bodies that it affects. For example, if your mechanism simulation starts from an initial static state, then you should make sure that the input motion has zero initial velocity. The motion input overrides the body initial velocities, if they are in conflict.
If you decide to use velocity inputs, be aware that the position is satisfied only to the integration error specified in PARAM_TRANSIENT. Likewise, for acceleration inputs, the velocity and position are only satisfied to the integration error specified. Therefore, you may see some drift from the analytical solution. This is a limitation of any scheme based on numerical integration.
It is useful to view the reaction force/torque time histories due to the motion constraint. It tells you how much force/torque is needed to achieve the given motion. You can decide whether or not this is realistic. Furthermore, it sometimes makes better physical sense to replace the motion with applied forces coupled with control laws. Remember that motion in a dynamic analysis is treated as a "hard" constraint with no room for compliance.
Motions may only be functions of time. The current implementation does not allow it to be a function of other system displacements, velocities, accelerations, reaction forces, and applied forces.

Modeling Contact Forces

MotionSolve contact capabilities:

The contact force model is based on penalty formulation. It is similar to the impact function based contact force model available in ADAMS. Although it is called Poisson in MotionSolve, its implementation does not resemble the Poisson approach in the ADAMS solver.
Both intermittent and persistent contact, including colliding, sliding, rolling, and spinning contact, are supported.
Friction is supported.
Multiple contacts are also supported. Contact can occur at multiple points, or vertices, and/or edges or facets on the same object.
Arbitrary contact surfaces may be defined used an arbitrary collection of polygons.
The contact surface may be completely general. MotionSolve does not assume concavity, continuity, or any other limitation on surface curvature or connectivity.

MotionSolve does not support the following:

Contact between non-surface objects. For example, curves, lines, and points.
Constraint-based contact model. For example, Linear Complementary Programming (LCP)-based contact algorithm, which is popular among most high-speed game multibody solvers.
User subroutines for contact force definition.
Direct use by the solver of a Parasolid geometry file.

Contact modeling tips:

Start your modeling with Contact friction set to Off.
Some experimentation is usually required with values of penalty and coefficient of restitution to get a realistic and stable result.
If your model is non-stiff and the contact is intermittent, it may be better to use the ABAM integrator. Stiff models typically have eigenvalues with very large negative real parts.
Start with a relatively small INTEGR_TOL and HMAX, and then tighten it as necessary.
Reduce the solver parameter HMAX if the surface is stiff, thin or both. In case of contact with thin parts, too large an HMAX setting may lead to the contact event being missed.
The contact friction force parameters mu_static, mu_dynamic, and stiction_trans_vel often have a strong effect on the contact behavior as well as the simulation speed. Some tuning is often necessary to get realistic and stable results.
If the addition of frictional forces causes numerical difficulties or simulation slowdowns, gradually increase the values for the transition velocities and reduce the coefficients of friction.
The current implementation for contact has difficulty when the penetration surface encounters edges. There is a discontinuous jump in the contact normal resulting in a spike in the contact forces. It may be helpful to smooth out the edges on the rigid body geometry. If this is not possible, consider extending the contact geometry such that an edge is not encountered in the rigid-rigid contact.

The table below shows some commonly encountered simulation problems and their solutions.

Issue

Remedy

Contact not Detected

Decrease H_MAX.
Decrease error tolerance.
Increase penalty.

Integration Failure

Decrease H_MAX.
Decrease penalty.
Increase error tolerance.
Decrease coefficients of friction.
Increase transition velocities.
Add damping to stiff, undamped entities in the model.

Integration Difficulty at Initial Condition

Check for whether parts are penetrating at model configuration.

Contact Force Pulls Bodies Together Instead of Repelling Them

Ensure that surface normal vectors are pointing outward from the body surface, not inward. Surface normals can be visualized using HyperMesh.

Modeling Flexible Bodies

Avoid selecting interface nodes that are too close together. This increases the likelihood that modes may be almost linearly dependent, which causes difficulty in the solution.
Interpret flexbody damping carefully. The modal damping ratio is applied to component modes that, in general, do not correspond to the physical vibration modes of your component.
Verify flexible bodies before using them to ensure that the proper number of fixed interface eigenmodes have been selected.
A fine mesh is usually not necessary for component mode synthesis as only a few fixed interface eigenmodes are needed. Most often people use too fine a mesh, rather than too coarse.
Use the full set of component modes in a multibody simulation. Avoid deactivating some of them to gain computational speed. This may cause integration failure in some cases. You may release some of the nodal degrees of freedom to reduce the set of models. See the ASET topic in the OptiStruct online help.
OptiStruct provides several options to reduce the size of the H3D file without sacrificing accuracy. See the tutorial Generating a Flexible Body for use in MotionSolve - OS-1930 in the OptiStruct Tutorials online help.

Tuning Solver Parameters

In general, the dynamic simulation results in MotionSolve do not depend on the print interval. However, if a print interval smaller than the time step is specified, MotionSolve changes the time step to be equal to the print interval. However, the quasi-static and kinematic simulation results are strongly affected by the print interval, which equals the step size in these cases. Too large of a value for this parameter may lead to simulation failure.
Typically, the stability of a MotionSolve dynamic simulation improves as the error tolerance and H_MAX parameters are reduced. However, the run time may increase.

User-defined Subroutines

Is it possible to mix Fortran and C source files in a single DLL? The answer depends on which types of subroutines are being used. The user defined subroutines can be categorized as:
- Type 1 - Modeling subroutines, such as GFOSUB, DIFSUB, and COUSUB. These have special meaning to the solver.
- Type 2 - All other subroutines that are not of Type 1. Typically, a Type 2 subroutine is called from a Type 1 subroutine or other Type 2 subroutine.
If you have multiple subroutines of Type 1 written in Fortran and C, then you are required to separate them into different DLLs. For example, if you have GFOSUB and DIFSUB in Fortran, but COUSUB in C, then you would build the Fortran and C subroutines into two different DLLs.
If all your Type 1 subroutines are in one language, then you do not need two DLLs. For example, if all Type 2 subroutines are written in C and all Type 1 subroutines are written in Fortran, then you can use the instructions for building the Fortran DLL and just insert the C source in the project. Alternatively, you may build the C code into a static library and include it in the Fortran project.
Note: Even when all Type1 subroutines are in one language, you can build them into many DLLs. However, each DLL is a separate entity. You cannot have a subroutine in one DLL calling another subroutine in a different DLL.