ADAMS/Solver

New functionality and features have been added to both ADAMS/Solver (C++) and ADAMS/Solver (FORTRAN). To help you identify the changes, this section is divided into three categories: both solvers, C++ only, and FORTRAN only.

Speed improvement for 3D solid-to-solid contact (both solvers)

Contact between tessellated 3D solids is now the default. All 3D solid geometry (with the exception of sphere) is automatically tessellated using a very fine mesh. Contact between solid geometries is now treated as contact between a pair of meshes. This is significantly easier and faster than calculating exact contact between two arbitrary geometries. Consequently, contact between 3D geometries is now significantly faster. In our testing, we have seen speed increases ranging from a factor of 1.5 to 150.

Contact between tessellated geometry does not use the Parasolid geometry engine, and therefore avoids many of the software errors associated with deficiencies in Parasolid. Contact location and normal calculations are more robust in this release.

The PREFERENCES statement allows you to specify the mesh refinement with the CONTACT_FACETING_TOLERANCE argument. You can use the CONTACT_GEOMETRY_LIBRARY argument to revert back to the Parasolid engine.

Experimental features include:

• Analytical Solids
  The geometry engine is not used to find the contact point in certain cases involving contact with spheres; no tesselation is required. See Knowledge Base Article 10534 for details.

• Contact Mesh Visualization
  Visualization of the tessellated geometry can be achieved by setting an environment variable, MDI_ADAMS_SHELL_FILE_PATTERN, that causes .shl files to be exported at the start of a simulation. See Knowledge Base Article 10495 for details.

• Shell-to-Shell Contact
  Support of shell files for EXTERNAL geometry makes shell-to-shell contact possible in ADAMS/Solver. However, there currently is no support for this in ADAMS/View. This capability is useful when your geometry is complex or comes from a CAD system that doesn't support the Parasolid file format. The shell files can be in either stereolithography (.stl) or shell (.shl) format and must meet two criteria: 1) comprised of triangles only (no quadrilaterals allowed), and 2) are closed (that is, defining an enclosed volume). For an example see Knowledge Base Article 10530.

• Contact Trace
  You can trace out the path of a contact in the animation window if you set the MDI_AVIEW_EXPERIMENTAL environment variable. See the Knowledge Base Article 10524 for details.

Contact between lists of geometry (both solvers)

You can specify contact between a list of geometries on one body and another list on a second body (for example, IGEOM=1, 3, 5 and JGEOM = 2, 16). You no longer need to have several individual CONTACT statements to model multiple contacts between two bodies. This feature works for both 2D and 3D geometries and has the effect of making the modeling simpler and more intuitive. An unexpected benefit is that simulations are often faster when multiple CONTACT statements are replaced with a single CONTACT statement.

Alternatively, your complex geometries may now be disassembled into a set of simpler geometries. This often speeds up the contact detection and can also make it more accurate and robust.

Broader availability of contact incident data (both solvers)

Contact incidents may be postprocessed in more detail. Contact incident data (such as detailed information about the kinematics and kinetics at each of the contact points) is now stored as part of the simulation results when using the .xrf format (XML results file). These results can be plotted in ADAMS/View. Contact kinematics include the following data for each contact incident:

• Location of the contact point on each body
• Normal and frictional force vectors
• Friction coefficient, slip deformation, and slip velocity
• Penetration depth and velocity

Polylines supported in CONTACT (both solvers)

The Polyline geometry type in ADAMS/View is now recognized as a Contact_Curve and, as such, can be picked off the screen and used for curve-based contact. This polyline is then represented as an ADAMS/Solver CURVE with ORDER=2, allowing sharp corners in geometry to be more accurately modeled. Polyline-based contacts could not be modeled in this fashion in the previous releases.

EVALUATE keyword for SENSOR Statement (both solvers)

The SENSOR element now has an additional keyword, EVALUATE, which takes a function expression as its argument. There is an associated measure, SENVAL(senid), in the expression language.

The purpose of this pair is that whenever the sensor triggers, it evaluates the EVALUATE expression and the resulting value is the value of SENVAL(senid) until the next time the sensor triggers.

Example:

SENSOR/1, FUNCTION = TIME\
, VALUE=5, EQ, EVALUATE = DY(3,2)

VARIABLE/4, FUNCTION = SENVAL(1)

This is an example of how you could store a computed value into a variable at time sensed during solution. With this sensor, when TIME equals 5, ADAMS/Solver uses the DY function to measure the distance between MAR/3 and MAR/2 and stores that distance value in VARIABLE/4.

Higher order curve fitting (both solvers)

Higher order curve fitting is now possible with the CURVE statement. The CURVE statement allows for higher order B-spline curve fitting of CURVE_POINTS through the new IORDER= argument. In the past, CURVE used a fourth order tension
B-Spline. The new method uses the Parasolid B-spline and defaults to fourth order. A higher order fit is useful in producing smoother accelerations when the CURVE is used with PTCV or CVCV constraints.

You use an environmental variable, MDI_SOLVER_SELECT, to choose the solver. If you don’t specify the solver you want, ADAMS/Solver (FORTRAN) is automatically used.

When you select ADAMS/Solver (C++), a checking function is invoked to see if it can handle the model (.adm file) being analyzed. If ADAMS/Solver (C++) cannot handle the model, control is automatically passed to ADAMS/Solver (FORTRAN). When an unsupported command (in the .acf file) is encountered, ADAMS/Solver (C++) issues an error message and subsequently halts the simulation.

The following steps show how specify the environment variable for UNIX and Windows.

To select ADAMS/Solver (C++) on UNIX, do one of the following:

• In the MSC.ADAMS Toolbar, change the Solver Select setting to C++.

• Set the following environment variable using the appropriate shell commands for your version of UNIX:
  
       Set MDI_SOLVER_SELECT to CXX.
  

To select ADAMS/Solver (C++) on Windows:

1. From the Start menu, point to Settings, and then select Control Panel.

2. In the Control Panel dialog box, select the System icon.

3. In the System Properties dialog box, select the Advanced tab.

4. In the Advanced tab container, select Environment Variables.

5. In the Environment Variables dialog box, create a new user variable as follows:

        Variable Name = MDI_SOLVER_SELECT
        Variable Value = CXX (for ADAMS/Solver (C++))
   

To specify ADAMS/Solver (C++) in ADAMS/View:

1. From the Settings menu, point to Solver, and select
   Solver Executable.

2. Set Choice to C++.
   
   This executes the command simulation set choice = cplusplus.

To specify ADAMS/Solver (C++) in an ADAMS/Solver .acf file:

• Use the PREFERENCES/SOLVER=CXX command.
  
  This is an undocumented feature and additional details can be found in the Knowledge Base Article 10431.

GCON Generalized CONSTRAINT statement (C++ only)

A new, expression-based constraint element, GCON, is available in the 2003 release. Nonstandard, user-defined constraints may be defined right inside the dataset as:

Vector operators added to expression language (C++ only)

This release marks the introduction of a new concept in the expression language of ADAMS/Solver. The function expression language has been enhanced with several new functions and operators. Function expressions can now use vector operations, as long as the final value of the expression is scalar. This often simplifies expression writing and is convenient when using the expression-based GCON constraint.

With these new functions and operators in place, you can now use 3D expressions. At this time, however, this 3D expression feature has limited availability and is only accessible from the GCON statement and command.

The new operators and functions are:

Examples:

DXYZ(1,2) is equivalent to [ DX(1,2), DY(1,2), DZ(1,2) ]

UV(DXYZ(1,2)) is equivalent to DXYZ(1,2)/DM(1,2) except that UV handles more gracefully the case where DM goes to zero.

MAG ( DXYZ(1,2) % DXYZ(3,4)) is the magnitude of the cross-product between two displacement vectors.

SURFACE statement (C++ only)

A new SURFACE entity is now supported. You can specify surface through data that is contained in a Parasolid file (sheet body), or user-defined subroutine (SURSUB). Surfaces are used to define SURFACE markers. These are then used to create a wide variety of constraints, previously not possible. Note that the surface must consist of only a single face.

The ADAMS/Solver (C++) uses the face (u-v) parameters as states for the surface marker, so they must be continuous in the region in which the surface marker moves (the parameters can be bounded or periodic).

CURVE and SURFACE markers (C++ only)

MARKERS can be defined to act like a CURVE or a SURFACE. These MARKERS can be used in any context where a regular MARKER could be. A variety of new and useful constraints can be modeled by defining standard "lower pair" constraints combined with CURVE and SURFACE MARKERS.

Some examples include:  

All standard kinematic measures (DX(…), VZ(…)) work as expected with CURVE and SURFACE markers. Using these measures, it is possible to obtain curve/surface tangent and normal directions, slip velocities, and so on, very easily.

PLANAR argument for PART statement (C++ only)

A new argument, PLANAR, indicates that a PART only has three degrees-of-freedom (global X and Y translations, and a rotation about the global Z axis). It is best to think of the planar as a regular 3D part with a built-in planar joint. This is a combination of elements often found in certain models that contain 2D subsystems, such as belts or chains. Unlike a part and a planar joint pair which combine to add 18 equations to an index 3 dynamic analysis in ADAMS/Solver, the planar part only adds 6 equations. Fewer equations can improve performance, but since the planar part can be contained in a full 3D MSC.ADAMS model, coexist with and connected to 3D part elements, performance will not match software for 2D dynamics analysis.

Speed improvement for FLEX_BODY (FORTAN only)

The computational efficiency in the FLEX_BODY element has significantly improved in the 2003 release. The improvement is obvious in all models that have flexible bodies. The most dramatic improvement is with flexible bodies that have high numbers of selected modes (such as SELMOD in .mtx file).

In an extreme case of a model dominated by a large FLEX_BODY that has 288 modes, the simulation times improved by 6.1 times. The improvements seen in a typical model are more modest, about 5-10%, and vary depending on how much the FLEX_BODY dominates the solution and how many enabled modes are in the FLEX_BODY. This change has no effect on the numerical results of the simulation.

ADAMS/Solver (C++) alternative for ADAMS/Car and ADAMS/Chassis (C++ only)

Previously, models created with ADAMS/Car or ADAMS/Chassis could only run using ADAMS/Solver (FORTRAN). Now, the functionality gap between ADAMS/Solver (C++) and ADAMS/Solver (FORTRAN) has decreased significantly. This allows ADAMS/Solver (C++) to run models created in ADAMS/Car or ADAMS/Chassis. This progress is part of the continuation of our long-term transition plan for advancement of ADAMS/Solver (C++).

The performance of ADAMS/Solver (C++) has improved since version 12.0. Our work up to this point has focused on functionality (getting everything working and making sure the answers are correct). You can now run most car models with ADAMS/Solver (C++) except those that use compliance matrix interface or that have the unsupported features outlined earlier (see table above).

MOTION statement may be dependent on VARVAL (C++ only)

You are no longer required to use ADAMS/Solver (FORTRAN) when using a VARVAL function to define a MOTION element. In fact, it works considerably better in ADAMS/Solver (C++). For example, in ADAMS/Solver (C++) during velocity ICs, the motion will be subject to the time derivative of the variable. ADAMS/Solver (FORTRAN) just uses zero. In order to preserve legacy behavior, MOTION will not transmit reaction forces through its function expression.
For this reason, you are still not encouraged to introduce state dependencies through motion functions. You should use the new GCON element to create complex constraints rather than the MOTION element.

MFORCE support (C++ only)

It is no longer a requirement to use ADAMS/Solver (FORTRAN) when using the MFORCE. For details see What's New in ADAMS/Flex.

MARKERs on flexible bodies (C++ only)

It is no longer a requirement that the location of a marker on a flexible body be coincident with a node. For details see What's New in ADAMS/Flex.

Extended modeling element compatibility for flexible bodies
(C++ only)

All joints, joint primitives, and motion generators can now be attached directly to a flexible body. For details see What's New in ADAMS/Flex.

Modal coordinate function expressions for flexible bodies
(C++ only)

New function expressions are now available for flexible body modal coordinates and their first two time derivatives. It is no longer a requirement to use a user-written subroutine. For details see What's New in ADAMS/Flex.