.
David Sampson's Web Site: Home > AutoSim FAQ
This page features a number of frequently asked questions (and answers!) related to Mechanical Simulation Corporation's multibody dynamics code generator, AutoSim. The most recent additions to the FAQ are marked .
If you have questions, answers, tips, comments or corrections that you think should be included in this FAQ, please contact me. Wasting time isn't wasteful anymore if you can write it up and keep other people from wasting time.
(equilibrium) command work?
(linear)?
*drop-small-terms*, *absolute-drop* and *small-order* affect the reliability of linearisations using (linear)?
Running out of memory is sometimes a problem with input files that define many preprocessor (AutoSim) variables using the setsym command. This means that when you reset, memory will not be recovered unless you re-process exactly the same file. If you are going to process another AutoSim model, you may need to restart AutoSim to avoid running out of memory.
Contributed by Stephen Riley (riley@trucksim.com)
To start AutoSim and the Allegro LISP environment under which it runs, double click on the AutoSim shortcut icon. The full path is: c:\autosim\lisp.exe c:\autosim\asim28.img. The file c:\autosim\_config.lsp is loaded on startup.
To load a LISP file into AutoSim, choose File - Load from the pull-down menu, or use the shortcut (CTRL + L).
AutoSim can be used to generate C source code. Choose Analyses - Write C Code from the pull-down menu to write a C source file. As of AutoSim Version 2.8, the header file (e.g. sim.h) for main program file is necessary only for simulation files that refer to multibody data structures as global variables in external routines.
AutoSim can also generate MATLAB code. Since MATLAB is a linear algebra package, AutoSim must linearise the dynamic system before writing MATLAB code. Replace (finish) with (linear). Then choose Analyses - Write MATLAB Code from the pull-down menu to write a MATLAB file. Some other minor changes to the code may be necessary. (See also: When is it safe to use (linear)?)
Choose Analyses - Write RTF Formatted Eqs from the pull-down menu to write the equations of motion in Rich Text Format.
Contributed by David Sampson (david@sampson.org)
This section contains information specific to the Microsoft Visual C++ 5.0 compiler.
To start Microsoft Developer Studio, double click on the Microsoft Visual C++ shortcut icon. The full path is: c:\Program Files\DevStudio\SharedIDE\bin\msdev.exe.
Next you have to create a project, which consists of all the source files required to build a stand-alone executable. Select File - New (CRTL + N) from the pull-down menu and then choose Win32 Console Application as the application type. Specify the directory (e.g. ...\models) and the name of the new project (e.g. vehicle). Developer Studio will compile the code to a simple command line application that runs in an MS-DOS window. (Note that a detailed working knowledge of the Microsoft Foundation Class Library, MFC, is needed to create graphical Windows applications in C++.) For convenience, it is best to relocate the C source files produced by AutoSim into the new project directory.
Insert all C source files that make up the application into the project workspace by choosing Project - Add to Project - Files from the pull-down menu. It is also necessary to insert one or more AutoSim library files into the project workspace:
simlib.c is required for all AutoSim-generated C programs
errorf.c is required for all stand-alone AutoSim-generated C programs
simlibio.c is required for all AutoSim-generated C programs that require file i/o
gear.c is required for all AutoSim-generated C programs that use the stiff integrator option
diff_fun.c contains routines that support some experimental differentiable versions of math functions that normally have singularities
These library files are located in the AutoSim common library directory c:\autosim\lib\clib_src\.
It is not necessary to explicitly add header files to the project workspace if these are included by way of #include statements within the C source files. However, these header files must be on Developer Studio's include search path, which must therefore include:
c:\autosim\lib\cinc\
c:\autosim\lib\clib_src\
This path can be set by selecting Tools - Options from the pull-down menu and navigating to the Directories tab.
The project can be compiled and linked in one step by selecting Build - Build ???.exe (F7) from the pull-down menu. The progress of the compilation and linking is displayed. AutoSim generates error-free ANSI C code, so any errors are most likely caused by incorrect path settings or by failure to include the necessary common files (e.g. simlib.c) in the project workspace.
The executable can be run from within Developer Studio by selecting Build - Execute ???.exe (CTRL + F5) from the pull-down menu. The executable can also be run independent of Developer Studio from the MS-DOS prompt.
Contributed by David Sampson (david@sampson.org)
This section contains information specific to the Microsoft Visual C++ 5.0 compiler.
Visual C++ reports a series of warnings of the type: truncation from 'const double ' to 'float '
This problem is caused by the fact that C did not originally have implicit type conversion.
To fix this problem, set the real_as variable in the file deftypes.h to double.
Alternatively you can switch off the compiler warnings, although this also turns off warnings you probably do want to see.
Stephen Riley suggests using double precision for everything, only switching to single if it can be shown to make a needed speed difference for some particular application (e.g. hardware in the loop).
Contributed by Stephen Riley (riley@trucksim.com)
The root locus in the AutoSim Introductory Guide is incorrect. The correct root locus features right-half plane poles. The linearisation is evaluated about nonzero Q's, and the linearised system is unstable in this case, even though the full nonlinear model is stable.
The correct values for the system poles are:
>> eig(MatrixA) ans = -1.5864 +23.9137i -1.5864 -23.9137i 1.1585 + 5.2052i 1.1585 - 5.2052i -1.2821 + 5.2086i -1.2821 - 5.2086i -1.1335 +18.8986i -1.1335 -18.8986i plus several eigenvalues at the origin
From the example files on the AutoSim 2.8 CD, lin.m is correct, space.m is not.
Contributed by Stephen Riley (riley@trucksim.com), David Sampson (david@sampson.org)
First, ensure that you run in double precision. (See also: Why do I get so many warnings when I compile my C code?) The Jacobian matrix of the force array is computed by numerical perturbation. Without double precision, some of the numerical derivatives come out as zero, whereas they should be small non-zero numbers.
Second, you should add the following patch to the default _config.lsp that ships with AutoSim 2.8:
(defun validate-equilibrium (&optional expand-zees)
(unless (eq *analysis* 'equilibrium) (equilibrium))
(unless (remove *time* *outputs* :key #'output-exp)
(add-standard-output))
(finish-update 'output)
(status-report "removing unused equations...")
(validate-hide)
(dolist (x *outputs*) (validate-exp (output-sym x)))
(dolist (x *external-subroutines*)
(when (member (call-where x)
'(derivative discrete echo init input))
(mapc 'validate-exp (call-args x))))
(when (declared-variable-p *mass-matrix-symbol* 'dyvars)
(dotimes (i *p*)
(validate-exp (aref *force-array* i))
(dotimes (j *p*) (validate-exp (aref *mass-matrix* i j)))))
(dolist (x (eqs-list *time-eqs*))
(when (call-p x) (mapc 'validate-exp (call-args x)))
(when (and (sym-p x) (or (eq (sym-symbol x) *jac-symbol*)
(eq (sym-symbol x) *errf-symbol*)))
(validate-exp x)))
(validate-eqs *initnr-eqs*)
(when expand-zees (expand-zs-in-eqs))
(validate-renumber)
(validate-comments *time-eqs*)
(validate-count)
(format t "~&Time since reset: ~a~%" (elapsed-time))
(status-report "")
(setf *replace-dots* nil
*analysis* 'finished-equilibrium))
Contributed by Stephen Riley (riley@trucksim.com)
Wondering what (if anything) is the difference between the following LISP commands?
(install-units* 'mm :name "mm" :gain 1000.0 :gen-name "Distance") (install-units mm :name "mm" :gain 1000.0 :gen-name "Distance") (install-units "mm" :name "mm" :gain 1000.0 :gen-name "Distance")
LISP has pretty confusing syntax. To allow the user to type in math expressions more easily, AutoSim commands and functions read f-strings, where the f stands for FORTRAN... so math (with the added capability of vector algebra) should be written as if you were typing for FORTRAN.
To support this, AutoSim has a parser that reads f-strings and translates them into LISP. In LISP, all functions (now speaking of LISP, not AutoSim functions listed in the manual) must be passed LISP syntax. If the AutoSim command or function accepts and f-string, it is coded as a MACRO in LISP. This calls the parser and passes the result to a LISP function.
In the above example, INSTALL-UNITS is a LISP macro. INSTALL-UNITS* is a LISP function. The parser reads "mm" and mm and puts the ' in front and sends it to INSTALL-UNITS*.
If a call to the parser is not needed for an AutoSim command or function, usually it is only coded as a LISP function. In such cases, the starred (*) version of the AutoSim command or function does not exist, and the unstarred version is itself a LISP function.
When the parser is invoked, all expressions need double quotes. Symbols, such as mm above or [nx] are the simplest expressions, so quotes will not hurt. But, the parser also knows to evaluate symbols to a quoted version of the symbol, so quotes for JUST symbols are not needed. If in doubt, use quotes.
Examples:
(set-units foo1 "F") ; quotes not needed but OK (set-units foo2 F) ; same as "F" (set-units foo3 "F/L") ; quotes needed (set-units foo4 F/L) ; dangerous, don't use
Contributed by Stephen Riley (riley@trucksim.com)
The code in the AutoSim Introductory Guide references tables using syntax of the form:
road(dot([nx],pos(af0)))
whereas the sample code on the AutoSim 2.8 CD uses a newer syntax of the form:
road(dot([nx],pos(af0)),1,1)
Multiple arguments are used for compact notation and efficiency. Of the three arguments:
itab number - the itab'th table of data, but with the same function name
inst number - the inst'th copy of the itab'th table.
Consider the example of a tractor-semitrailer model with 5 axles. Say the first axle (the steer axle) has 2 tyres, and all others have 4. The tyres on any particular axle are all of the same kind, but each axle can have a different type of tyre. Say you need to install a table for the tyres for cornering stiffness Ka versus vertical load Fz for the tyres. You could call the table ka_fz and install ntab = 5 and ninst = 4. Then, you could refer to the tyre table for each tyre as follows:
ka_fz(@fz_l1, 1, 1) --> Left tyre, first axle ka_fz(@fz_r1, 1, 2) --> Right tyre, first axle ka_fz(@fz_l2_o, 2, 1) --> Left outside tyre, 2nd axle ka_fz(@fz_l2_i, 2, 2) --> Left inside tyre, 2nd axle ka_fz(@fz_r2_o, 2, 3) --> Right outside tyre, 2nd axle ka_fz(@fz_r2_i, 2, 4) --> Right inside tyre, 2nd axle ka_fz(@fz_l3_o, 3, 1) --> Left outside tyre, 3rd axle ka_fz(@fz_l3_i, 3, 2) --> Left inside tyre, 3rd axle ka_fz(@fz_r3_o, 3, 3) --> Right outside tyre, 3rd axle ka_fz(@fz_r3_i, 3, 4) --> Right inside tyre, 3rd axle ka_fz(@fz_l4_o, 4, 1) --> Left outside tyre, 4th axle ka_fz(@fz_l4_i, 4, 2) --> Left inside tyre, 4th axle ka_fz(@fz_r4_o, 4, 3) --> Right outside tyre, 4th axle ka_fz(@fz_r4_i, 4, 4) --> Right inside tyre, 4th axle ka_fz(@fz_l5_o, 5, 1) --> Left outside tyre, 5th axle ka_fz(@fz_l5_i, 5, 2) --> Left inside tyre, 5th axle ka_fz(@fz_r5_o, 5, 3) --> Right outside tyre, 5th axle ka_fz(@fz_r5_i, 5, 4) --> Right inside tyre, 5th axle
This way you avoid needing to have separate names for each table. All calls to ka_fz where the second argument is the same (itab) refer to the same data. Also, each instance of an itab has its own set of pointers to the data. The interpolation starts at the place where it left off last time. This saves a lot of time.
(setsym *old-table-arguments* t) sets the table functions to only accept the first argument, as per the syntax in the AutoSim Introductory Guide. It is, however, best to work with (setsym *old-table-arguments* nil), which is the default.
Contributed by Stephen Riley (riley@trucksim.com)
(equilibrium) command work?For the (equilibrium) command, the solution is computed by forming the expressions for the force array f in the dynamical equations M * Udot = f. The equations of motion (the derivatives of the generalized coordinates (Q's) and generalised speeds (U's)) are not derived. Instead, the vector equation f = 0 is formed. In general, AutoSim allows f to be a function of U's, Q's and t, i.e. f = f(U,Q,t). However, all U's are set to zero, forcing the system to become purely static. Thus, f = 0 becomes f(Q,t) = 0, forming a set of algebraic (nonlinear in general) constraint equations on the Q's. These are solved at every time step by Newton-Raphson iteration.
It is valid to use the (equilibrium) command for systems have holonomic constraints (i.e. you have used add-position-constraint, no-movement or motion to impose constraints). However, (equilibrium) will not work for systems with one or more nonholonomic constraints. In such cases, the number of independent Q's is greater than the number of U's (which is equal to the number of elements in f). AutoSim will signal an error in such cases, since there are more variables than equations and so a result can not be found. A nonholonomic constraint implies that one or more of the U's are non-zero, meaning the system is physically not static. (AutoSim is not able to solve for equilibrium about non-zero U's, i.e. f(Q,U,t) = 0.)
The Newton-Raphson iteration will not converge if there is no equilibrium point. Additionally, if there is a solution, then the initial values of the Q's must be close enough (a good guess) to the solution, or else it will not converge. At each time step, the values of the Q's for equilibrium at the last time step are used as the initial guess for the new iteration. This means that the time step you select to cause your inputs to change must be small enough that the solution for the previous step is a good guess for the next step. And even if your step is always small enough, your inputs may eventually move the system into a configuration in which there is no solution and the iteration will again (rightly) fail.
In using the (equilibrium) command, you would best be served to operate between two sets of inputs that you know have equilibrium solutions. You can determine this from a (dynamics) solution about these inputs for the same problem.
Contributed by Stephen Riley (riley@trucksim.com)
(linear)?Do not use the (linear) command for systems that have position constraints (i.e. you have used add-position-constraint, no-movement or motion to impose constraints). It is OK to use it for systems in which you use the command add-speed-constraint, but only if the constraints imposed by add-speed-constraint are truly nonholonomic (i.e. not integrable). This means that it is not possible to also use add-position-constraint with add-speed-constraint to eliminate an independent Q as well. (When holonomic constraints are present, the system (in general) cannot be linearised in purely symbolic form - some numerical iteration is required. It is quite a tricky problem.)
If you need to linearise a system with holonomic constraints, Stephen Riley has some code to link to that will perturb the entire system numerically to form the A-matrix.
Additionally, note that the problem with symbolically linearising systems with holonomic constraints is only a serious problem when the system has closed loops (e.g. the 4-bar linkage). In all other cases, holonomic constraints can be accounted for by using parent-child relationships (i.e. a tree-topology). Thus, add-position-constraint, no-movement and motion can be avoided in these cases.
Contributed by Stephen Riley (riley@trucksim.com)
*drop-small-terms*, *absolute-drop* and *small-order* affect the reliability of linearisations using (linear)?The use of *drop-small-terms*, *absolute-drop* and *small-order* introduces a degree of approximation into the equations of motion. These modified (simplified) equations are useful for estimating the time response of the fully nonlinear system. However it is not advisable to use these equations for (linear) analysis in AutoSim. The linearisation process includes a symbolic differentiation of the equations of motion, and there may be important differences between the computed derivatives of the full and modified equations of motion. For this reason, the options *drop-small-terms*, *absolute-drop* and *small-order* should be set to NIL when using (linear).
Contributed by Stephen Riley (riley@trucksim.com)
