ADAMS/Car  

What's New

New data-editing dialog boxes 

As part of the ongoing ADAMS/Car-ADAMS/Chassis merger project, a new dialog box was added for editing component data. This new dialog box (named Property File Editor) allows you to store data in XML format. The following elements use this new dialog box format:

• Air springs
• Bumpstops
• Bushings
• Dampers
• Reboundstops
• Springs

To access the Property File Editor:

1. Launch ADAMS/Car Standard Interface.

2. Open a subsystem.

3. Right-click a bushing and then select Modify.

4. Right-click the Property File text box and select an .xml file from the acar_shared database.

5. Select , and then save your changes.

Support to select ADAMS/Solver (C++) for running simulations 

A switch has been added that allows you to select either ADAMS/Solver (FORTRAN), which was the default for all previous releases, or ADAMS/Solver (C++). There are several features and capabilities (especially with respect to contacts and flexible bodies) that are unique to the ADAMS/Solver (C++). For more information, see What's New for ADAMS/Solver.

To select a solver:

1. Launch ADAMS/Car Standard Interface.
   
   
2. From the Settings menu, point to Solver, and then select Preference.
   The default is None. The other choices are F77 or CXX.

Note: The .acf file contains a reference to the ADAMS/Solver selection. If you enable this option, it allows you to see which version of ADAMS/Solver was used for the simulation.

Auto-plugin capability

A Plugin Manager has been added for the 2003 release. The Plugin Manager is an extremely useful tool that allows you to select all of the plugins you want to load or unload at one time. You have the choice of loading plugins for just a single session or every time, automatically, at startup.

To access the Plugin Manager:

1. Launch ADAMS/Car Standard Interface.

2. From the Tools menu, select Plugin Manager.
   
   The Plugin Manager dialog box is displayed as shown next.
   
   
   
   
3. Select Load and/or Load at Startup for all the plugin products you want to use.
• Load loads the plugin for use in the current session.
• Load at Startup loads the plugin every time, automatically, at startup.
4. Select OK.
   The selected plugin products are now loaded. If you exit and restart ADAMS/Car, those products for which you selected Load at Startup will be automatically loaded.

Note: You need a valid license for each plugin to load that plugin in ADAMS/Car.

Improved database search control

In version 12.0, if ADAMS/Car could not locate a file (template, property file, and so on) in the specified CDB or directory, it searched all defined ADAMS/Car databases according to their assigned search order for a like named file, taking the first like named file found.

For this release, ADAMS/Car no longer searches all the defined ADAMS/Car databases by default when it cannot locate a file. However, you can re-enable the searching by setting the MDI_CDB_SEARCH environment variable to yes. This is done by issuing the following command in the Command Navigator:

variable set variable_name=do_search &
 integer_value=(putenv("MDI_CDB_SEARCH","yes"))

If you want to enable CDB searching for all ADAMS/Car sessions, including ADAMS/Car solver simulation, add the following line to your ADAMS/Car configuration (.acar.cfg) file:

ENVIRONMENT MDI_CDB_SEARCH yes

Example:

If the CDB searching is enabled and you have a subsystem file that contains a spring which references the property file:

‹v11›/springs.tbl/mdi_0001.spr

If the file mdi_0001.spr does not exist in the ‹v11› database, or if the ‹v11› database is not defined in your ADAMS/Car session, ADAMS/Car strips the CDB path (‹v11›/springs.tbl/) from the property file name, and searches for a spring file named mdi_001.spr in any defined ADAMS/Car database according to their assigned search order (see the figure below).

According to the search order in the figure above, ADAMS Car searches first for mdi_0001.spr in ‹beta_day_2003›/springs.tbl/, then in ‹acar_shared›/springs.tbl/, and finally in ‹private›/springs.tbl/. ADAMS/Car uses the first mdi_0001.spr found and shows the file location in the Message Window and log file.

Converting a version 12.0 database to version 2003

ADAMS/Car 2003 allows both ADAMS/Driveline and ADAMS/Engine as plugins to ADAMS/Car. This increases your vehicle model's fidelity by adding detailed engine and powertrain subsystems. This also allows you to create a complete Functional Digital Vehicle.

Because of the plugin changes, it was necessary to rename the shared databases for ADAMS/Car, ADAMS/Engine, and ADAMS/Driveline. In version 12.0, ADAMS/Car, ADAMS/Driveline, and ADAMS/Engine had the following database aliases and names that were stored on disk:

Product:	Database alias:	Database name on disk:
ADAMS/Car	‹shared›	shared_car_database.cdb
ADAMS/Driveline	‹driveline›	driveline.cdb
ADAMS/Engine	‹shared›	shared_engine_database.cdb

For version 2003, we have standardized the shared database names for all three products. The table below shows the changes:

Product:	Database Alias:	Database name on disk:
ADAMS/Car	‹acar_shared›	shared_car_database.cdb
ADAMS/Driveline	‹adriveline_shared›	driveline.cdb
ADAMS/Engine	‹aengine_shared›	shared_engine_database.cdb

Because of these changes, you must modify all existing user databases that reference the new MSC.ADAMS distributed databases. Below are instructions on how to modify user databases using a python script provided with version 2003.

To modify user databases:

Note: We recommend that you save your files before each database conversion.

1. From the Tools menu, select Database Management, then Version Upgrade and Shared Database Alias as shown below.
   
   

   

   
   
2. If you are running ADAMS/Car with an unconverted CDB, it assumes that any ‹shared› reference should be ‹acar_shared›, so you can immediately use existing databases.
   
   If you are a Functional Digital Vehicle user, you will need to convert the databases so there is no confusion between the ADAMS/Car ‹shared› and the ADAMS/Engine ‹shared› CDBs.

Full-vehicle analysis using ADAMS/Driver and ADAMS/3D Road

The submission dialog box for full-vehicle analyses was modified to support ADAMS/3D Road. In the ADAMS/Car 12.0 Service Pack, we introduced ADAMS/3D Road that allows you to define a 3D smooth road using a TeimOrbit property file. In 12.0, it was possible to perform a full-vehicle analysis using ADAMS/Driver, but knowledge about file extensions was required to properly set up the analysis. This sometimes caused confusion.

In ADAMS/Car 2003, the procedure for running a full-vehicle analysis and using ADAMS/Driver with ADAMS/3D Road has been simplified. A new button has been added to the existing interface that allows you to choose between a driver course or a 3D smooth road. Depending on this choice, you are presented with a custom interface asking for the relevant input files to be defined.

When using a traditional driver course, you must specify a driver course data file (.dcd) and a road data file (.rdf). The Dcd file is used to specify road path and draw graphics, and the .rdf file is used to specify the tire/ground contact. When using the 3D smooth road option, you only need to specify a single road data file (.rdf). This .rdf file must contain relevant data to be used with the 3d smooth road formulation. We have included some additional 3D smooth roads in the acar_shared database.

ADAMS/Driver uses the data in the 3D smooth road file for path definition. ADAMS/Tire uses the data in the file to define tire/ground contact.

Extensible end and abort conditions

A new user-defined element, condition sensor, has been introduced in this release.

The condition sensor represents a relationship between a measurable solver quantity and a string label identifier that can, for example, be used in a driver control file (.dcf) to define an end condition for ADAMS/Car full-vehicle analyses.

This new element allows you to extend the standard set of available end conditions and will be used in future releases to further enhance the capabilities of the driver control file.

For more information, see the ADAMS/Car online help.

Constant-radius cornering analysis

The constant-radius cornering analysis dialog box was modified to make it consistent with other cornering maneuvers. An option was also added to support the quasi-static skidpad setup. This feature allows you to choose between either a dynamic conditioning phase before the constant-radius cornering analysis starts or a quasi-static conditioning phase. If you choose not to use the quasi-static skidpad option, then text boxes are enabled for you to enter an entry distance (before cornering starts) and a settle time where vehicle transients are allowed to stabilize to steady-state vehicle behavior.

Straight-line acceleration analysis

The straight-line acceleration analysis dialog box was modified to make the default options more intuitive. Rather than using throttle ramp (rate of change of throttle position with respect to time), the interface was modified to use a step function. The new interface now has two text boxes: final throttle and duration of step. The final throttle value specifies the position of the throttle at the end of the step. The final throttle value is represented as a percentage of throttle travel; 100% would be a wide open throttle. The duration of step value specifies how long it takes to step from the initial throttle value to the final throttle value.

The default gear position was also changed from 5 to 1. It did not make sense in most circumstances to start an acceleration test in 5th gear by default. The default steering input was changed from free to straight line, which means DriverLite is used to maintain a straight path. A new option, shift gears, has been added. By default, this is set to active, which means that DriverLite shifts gears based on information defined in your powertrain.

Straight-line braking analysis

The submission dialog box for straight-line braking analysis was modified to make the default options more intuitive. Rather than using brake ramp (rate of change of brake position with respect to time), the interface has been modified to use a step function. The interface now has two text boxes, Final Brake and Duration of Step. The final brake value specifies the brake force at the end of the step. The duration of step value specifies how long it takes to step from the initial brake value to the final brake value.

The default steering input was changed from Free to Straight Line. This means that DriverLite is used to maintain a straight path.

New bushing features and formulations

The bushing code for version 2003 has been modified and extensively rewritten to support the following features, only available with XML format property files.

• Optional 2D or 3D inter-axial coupling
• Wider choices of stiffness and damping force methods
• Ability to mix any force formulation with any damping formulation
• Hysteretic elastic force and k-fraction damping forces

The bushing component also supports both nonlinear (.bus) and linear (.lbf) bushing property TeimOrbit files. Your existing property files remain supported.

Bushings are modeled with ADAMS/Solver FIELD elements. FIELD's apply a translational and rotational action reaction force between two markers. For more information about the force formulation, see the Component tab in the ADAMS/Car online help. Here we present a brief description of the new features available with bushings in version 2003. Bushings support both XML and TeimOrbit format property files, but only with the new XML implementation you will have access to the new functionality.

Shape (coupling) methods

• Squared: No coupling between coordinate directions (equivalent to the standard BUSHING statement in ADAMS/Solver, but supports nonlinear force-deflection and force-velocity).
• Cylindrical: X and Y force-deflection characteristics are coupled, but Z force-deflection characteristic is independent (equivalent to the nonlinear bushing formulation in ADAMS/Car 12.0). Tx and Ty torque-angular-deflection characteristics are coupled in the same manner.
• Spherical: X, Y, Z force-deflections are coupled, and TX, Ty, and Tz torque-angular-deflections are coupled.

The bushing component supports a variety of stiffness and damping methods. Also, you may select different methods for each axis and different stiffness and damping methods for a single axis.

• Nonlinear spline based (equivalent to ADAMS/Car and ADAMS/Chassis 12.0 nonlinear bushing)
• Smoothed piecewise linear ()
• Hysteretic (previously available only in ADAMS/Chassis)

Damping methods

• Spline based ()
• K fraction ()

A final note about the new formulations:

Hysteretic stiffness implementation

• Uses two force-deflection splines: one for positive velocity and one for negative velocity.
• Computes the force by switching between the splines based on the sign of velocity, provided the velocity magnitude is greater than a prescribed value.
• Computes the force by blending the two splines when the magnitude of the velocity is less then a prescribed value.

K-fraction damping

• Damping force is proportional to the local stiffness
• Damping coefficient is user specified

For additional information about the equations, see the ADAMS/Car online help.

New air-spring component

You can now replace a coil spring with an air spring in the ADAMS/Car Standard Interface. Air springs are often used in heavy-duty trucks and occasionally in light trucks and passenger cars.

Air springs are modeled as a line-of-sight force acting between two parts at two hardpoints. The air spring force is interpolated as a function of spring deflection and trim load (initial internal pressure). Before analysis, ADAMS/Car reads the spring force verses spring deflection and trim load data from an XML air spring property file. For more information on the force deflection expression, see the Component tab in the ADAMS/Car online help.

Air-spring data collection starts with air-spring test data. Air springs are usually tested in two different ways: constant pressure testing and dynamic testing. Automotive suppliers, engineering manuals, and catalogues usually have detailed description and data pertaining to both testing methods, in particular:

• Constant pressure testing
  The air spring is filled to a particular gauge pressure and then is compressed with the resulting force measured from a force transducer. The test is performed with a constant pressure, therefore, air evacuates through a blow off valve. At this time it is not possible to create valid property files starting with constant pressure testing raw data.
  
  
• Constant air mass testing (dynamic data)
  This method tests the spring at a constant air mass. The air spring is filled to a particular pressure and then compressed. A measure of the force is taken using force transducers. The pressure in the spring is increased while the spring is compressed. Testing of the spring continues at various line pressures.

The data collected using the second method can be directly used to create valid property files. Part of the first exercise will be creating a valid XML file starting from an Excel spreadsheet describing the data of a typical air spring for vehicular applications.

To work with air springs:

1. Open an assembly with a coil spring.
   
   For example, MDI_Demo_Vehicle_lt.asy or TR_Front_Suspension.sub in the ‹acar_shared› database.

2. Right-click over the coil spring.

3. Select Replace.

4. Change Spring to Airspring (see figure below).
   
   

Linux operating system support (ADAMS/Car solver only)

ADAMS/Car adds support in the 2003 release for the Linux operating system. At this time, the support is limited to solver only. The graphical user interface portion of the product is not yet supported on Linux. We will add support for the ADAMS/Car interface in a future release.

Please see the Hardware and Software specifications, provided with your distribution and available on the MSC.Software Web site, for further details.

Items first introduced in the 12.0 Service Pack and included in the 2003 release

The 2003 release of ADAMS/Car includes items that were first introduced in the 12.0 Service Pack. If you did not install the 12.0 Service Pack for your MSC.ADAMS installation, note that the following items have also been included in the 2003 release of ADAMS/Car.

Example:

To mark .my_own_testrig compatible to .__MDI_SDI_TESTRIG, you would add:

variable create variable = .my_own_testrig.event_class &
  string_value = "__MDI_SDI_TESTRIG" &
  comments = "DO NOT REMOVE, USED BY ANALYSIS EXECUTION"

Issues resolved

The currently available entry points and their naming conventions are:
- mac_fil_ass_new_gen     =› mac_fil_ass_new_gen_custom
- mac_fil_ass_ope            =› mac_fil_ass_ope_custom
- mac_fil_ct13_?_upd       =› mac_fil_ct13_?_upd_custom (see also 32715)
- mac_ana_ful_sub           =› mac_ana_ful_sub_custom_pre
                                    =› mac_ana_ful_sub_custom_acf
                                    =› mac_ana_ful_sub_custom_pos

Scan the entry point macros for the list of required parameters to be added to the custom macros to function properly.

32044
A Target Database option has been added to the Template, Subsystem, and Assembly Save As dialog boxes, which allows you to specify where the files should be written, thereby resolving a common mistake of saving a file to the wrong database. The default writable database setting serves as the default value for this option.

32639
We resolved an issue where the suspension characteristic file (.scf) was corrupted because of failed analyses.

32640
Steering driver demand is now available as an output for quasi-static analyses.

32715
Customization entry points have been provided to allow those of you with user-defined elements to hook up your own template conversion code to the existing standard macro, thus eliminating the need to modify it (see also 30317 shown above).

For example, mac_fil_ct13_7_upd (the macro to convert version 13.6 templates to the ADAMS/Car 2003.0 compatible version 13.7) checks for the existence of a macro named mac_fil_ct13_7_upd_custom and executes it if found.

A custom conversion macro could look like:

   ! $template:t=model(_[^_]*):A

   for variable=$_self.loopObj &

    object =(eval(db_children($template,"ude_instance")))

      if condition=(db_type($_self.loopObj.object_value) == "my_ude")

         ude replace instance &

          instance_name=(eval($_self.loopObj[1])) &

          with_type=.my_lib.my_ude
		  
       end

   end

Items resolved in the 12.0 Service Pack and included in the 2003 release

This release includes several items that were first resolved in the 12.0 Service Pack. If you did not install the 12.0 Service Pack for your MSC.ADAMS installation, note that the following items have been included in the 2003 release of ADAMS/Car.

The comment dialog box now updates the comment under the respective user-defined element (UDE).

• Forces are always applied, regardless of the fact that the tire loses contact with the ground. The advantages of this implementation are:
• ADAMS/Solver is satisfied if the tire loses contact with the road and lateral forces are still being applied. This eliminates ADAMS/Solver failures.
• It is easier to understand that forces will always be applied.
  
  
• The moments generated by the lateral forces and longitudinal braking forces at the contact patch have their moment arm limited by the unloaded radius. This avoids the building of extremely high torques if the tire goes out of contact and the table falls.

• Braking and holding the steering wheel fixed to observe the turn-in characteristics.
• Braking and trying to maintain the path on which the vehicle is turning to observe the steering torque characteristics.

• Longitudinal Displacement (lon_dis (DX))
• Lateral Displacement (lat_dis (DY))
• Vertical Displacement (vert_dis (DZ))
• Lateral Velocity (lat_velocity (VY))
• Vertical Velocity (vert_velocity (VZ))
• Roll Rate (roll_rate (WX))
• Pitch Rate (pitch_rate (WY))
• Vertical Acceleration (vert_accel (ACCZ))

Known issues

Copyright © 2003 MSC.Software Corporation. All rights reserved.