Mechanical Engineer Best Practices

This section offers some common techniques to increase the performance of your simulations.

Using script, collision rules, and optimized variable settings, you can improve the stability and produce expected simulation outcomes. Optimization strategies are presented in the following sections.

Collision Detection Optimization

Analyzing and determining what should be simulated can help to reduce the amount of time required to solve simulation equations.

The following is a list of ways to optimize simulations using geometries.

MethodDescription
Analyze system behaviorSelect and model only surfaces which can collide. This can reduce the number of geometries in the system.
Use primitives when possiblePrimitives have a more stable contact generation and higher performance as collision geometries. It is preferable to use capsules rather than boxes or cylinders since the contact generation is smoother and will produce fewer contacts.
Use convex with compositesSplit complex shape into convex pieces and group them into a composite geometry to generate a single contact.
Limit amount of objects collidingOnly model objects of interest in the simulation.
Control number of contactsEach geometry generates up to four contacts. By using composite geometries, multiple geometries can be combined into a single composite geometry generating only up to four contacts total.
Use collision rules to disable pairs of geometriesReduce the number of geometries in the pair culling phase.
Geometry thickness considerationsIf geometry thickness is small compared to the part speed, select the Fast Moving checkbox.

Constraint Optimization

Constraints determine relationships between parts and are at the heart of a simulation.

Constraints operate on one or more rigid bodies to restrict the range of motion of a coordinate.

Constraint Relaxation

If the constraints of a mechanism are very stiff, it can potentially be time consuming for the dynamics solver to find a solution. To mitigate this scenario, constraint relaxation can be applied in order to simplify the problem and allow the solver to compute a solution in less time.

Constraint Best Practices

In addition to relaxation methods, the following list provides additional best practices to improve performance.

  • Disable/ Enable constraint
    • You can disable constraints that are not needed in the simulation to provide an accurate simulation. An example would be a door with two hinges. In Vortex®, one hinge constraint would be sufficient.
  • Disable collisions between constrained objects
    • In most circumstances, you are not concerned with the collision of two constrained parts. You can remove collision detection by clicking Collision Detection Rules in the Explorer panel and adding a rule containing the two constrained parts and deselecting Collide.
  • Soften limits
    • Softening the limits is similar to relaxation in that it reduces the complexity of the evaluation of the system resulting in more stable simulations. Stiffness can be adjusted based on physical parameters. Stiffness is in N/m.
  • Limit motor force to realistic values
    • By default the motor force is set to infinite power. Setting this value to a realistic value will produce more stable and reliable simulations.
  • Use some motor loss to avoid a rigid motor
    • Loss is similar to relaxation but instead of positional, loss refers to velocity. Adding loss allows the equations to be solved more efficiently. However, loss allows the constraints to slip even when the desired velocity is 0. The value set for Loss is a balance that must be evaluated by the user. Setting loss to 10e-6 is a starting point and observing the behavior for desired results. Adjusting loss will allow for fine tuning to a value that provides an efficient and accurate simulation.

Example of Overconstrained System

In the following example, we will determine if a system is over constrained and how to correct.

We will use the Chebychev-Kutzbach-Gruebler criterion to determine if a system is over-constrained. The criteria states that,

Number of Degrees of Freedom = 6 X Number of rigid bodies - Number of constraint equations

For example, we will take a simple door. We have one rigid body and two hinges typically. The hinge constraint has 5 constraint equations. Using the equation we have:

6 X 1 rigid body -10 (2 hinges with 5 constraint equations each)=-4

From the equation we see that the door is over-constrained. In Vortex, we would use only one hinge, giving us:

6 X 1 rigid body - 5 ( 1 hinge with 5 constraint equations)=1

This would be a system with the correct number of degrees of freedom.


Optimizing Collision Triangle Meshes

There are a number of strategies for optimizing triangle mesh collision:

Orienting Normals Properly

Triangle normals must point towards the outside of the object.

Note that very thin, single-sided features in triangle meshes such as fences made of a single layer of triangles, will cause problems in collisions and are to be avoided.

Avoid Overlapping Triangles

Triangles should not be overlapping. This causes generation of duplicate contacts and can cause instabilities and slowdown. This is particularly important when the triangles have opposite normals, such as in a thin wall.

Keep Walls Thick

Walls should be sufficiently thick, depending on the speed of colliding objects.

Vortex® allows a certain interpenetration for efficiency, so that fast-moving objects can potentially intersect both sides of a wall, causing contacts with opposite normals and serious instability.

Avoid Elongated Triangles

Triangles should not be too long and thin. This can happen when there is a single vertex with many edges in a model.

CAD software tends to create dense fans of long thin triangles to represent curved shapes. A lower level of detail with fewer triangles would behave as well or better for collision purpose with a significant performance increase.

Other Efficiency Considerations

Vortex has two types of triangle meshes: trees and grids:

  • Grids are arbitrary meshes that are mostly flat, such as a large terrain surface. The up axis of the grid can be any of the principal axes, X, Y or Z (the default). The grid efficiency is proportional to the spatial homogeneity of its triangles. Efficiency in collision with these objects is achieved by subdividing the set of triangles into a grid and so it is important to set the number of grid cells and their size correctly so that no grid cell contains too many triangles. Note also that for the moment it is not possible to collide two grids against each other.
  • Trees are the most generic of all but also the most expensive to use.

Building Stable Simulations

This section outlines things you can do to ensure you build stable simulations in Vortex® Studio. Consulting this page before building the simulation will avoid many issues later on.

We start with some general restrictions and recommendations that apply to any simulation project. The sub-topics at the bottom of the page go deeper into more specialized strategies.

Planning

Design reviews should be carried out on any mechanism of substantial complexity to figure out a strategy for breaking it down into parts, constraints, scripts, extensions, etc. Consider what you want to simulate and don't add unnecessary objects.

A design review can be carried out by any engineer in the group. Sometimes it is simplest for another person on the same project to do the review, since they might be most familiar with the work, but it can also be useful to expose others in the group to different projects.

Mass Properties

  • All parts should have reasonable mass properties (mass, centre of mass, and inertia tensor). If specs are provided for the object being simulated, those should be included, but even for unknown parts, a reasonable number should be used.
    • Masses for all objects must be strictly positive.
  • The mass ratio of constrained bodies must be taken into consideration.
    • Avoid large differences in masses between parts. Constraining a 1 kg part to a 100000 kg part reduces the effectiveness of the solver. Likewise, a long cable made of rigid bodies of mass 1 g attached to a mass of 1000 kg is more difficult to process correctly than the same cable holding a 100 g load.
    • The overall scale of masses is almost irrelevant, except for the values of the global compliance and damping parameters.
    • Careful tuning of the application is required for very large mass ratios, such as those that are well over 1000.
  • Inertia tensors must be symmetric and positive definite. If objects or inertia tensor are defined with negative values, Vortex Studio stops execution and invokes a fatal error handler.
    • Enable the Inertia Tensor accessory view in an assembly or mechanism. Anything that looks like a 1 m sphere is probably using the default mass properties.

Constraint Properties

  • When designing a dynamics model with constraints, it is important to try to avoid over-determinacy. See Determinacy for more information.
  • Ideally, all constraints should have realistic properties.
    • The default infinite stiffness should be set to a smaller, reasonable number, with appropriate damping added.
    • This is particularly important when constraints will interact with other constraints, since infinitely stiff constraints pushing against each other can cause instability.
    • Realistic forces in motors and locks must be taken into account. Use the relaxed constraint mechanism already provided in the core of Vortex to drive joints so that the processing of stiff forces of drivers is stable.
  • It is most important to set reasonable properties when:
    • The real constraint is expected to flex under load (i.e., crane boom sags when lifting).
    • The constraint might push against another constraint or contact.
  • Resetting the default properties of every constraint can take significant time, so it might not always be necessary to remove infinite stiffness. It is not required when:
    • The constraint will not be interacting with anything else.
    • The constrained part does not have collision geometry and has no other constraints.
  • Carefully tune the values of compliance, damping, and kinetic loss to obtain optimal performance.

Overconstrained Systems

  • Closed-loop mechanisms can potentially be overconstrained, which can cause constraints to fight against each other and cause very large forces, strange behavior, and solver instability.
  • Bad behavior related over overconstrained systems can be extremely difficult to debug, so it's very important to identify and eliminate them from the initial designs.
  • The only complete way of eliminating overconstrained systems is to reduce the number of constraints.
    • For example, many overconstrained systems involve hinges (five constraints). In many cases, the hinge could be replaced with a universal (four constraints) or a ball and socket (three constraints).
    • Prismatics (five constraints) can be replaced with cylindricals (four constraints).
  • Sometimes it is not feasible to replace constraints, so as a compromise, it is possible to add relaxation to some of the constrained axes.
    • This will generally prevent any of the bad behavior associated with overconstrained systems.
    • It does, however, still result in unnecessary additional constraints that the solver needs to deal with, so this should be considered only if removing constraint axes is not feasible.

Material Properties

  • Material properties should be set for all collision geometries.
  • The default material table is a reasonable starting point for most projects. It contains a few materials that are adequate for most situations.
  • Take into consideration the selection of all contact properties, including friction models and friction parameters.
  • Keep the overall number of materials small, since the number of material combinations grows exponentially, and becomes very difficult to manage.
  • It is best to not modify the properties of existing materials. Assets can then be transferred to other projects without changing behavior, since the material properties of the shared materials haven't changed.