1. SECTION 2 SETUP, WRITING AND CREATING
Example body page using the Section Header layout, shows correct fonts.
Course information shown in the footer needs to be updated for your particular class on the Slide Master. (View tab, Slide Master in Presentation Views group)

2. WHAT IS IN THIS SECTION Element types to override
Examples and documentation locations
Determining what to calculate
Inputs required
Programming languages

3. ELEMENT TYPES TO OVERRIDE
The general purpose of a subroutine for Adams/Solver is to 'override' the default behavior of an Adams/Solver element. There are exceptions to this rule, but in general this is the case.
A subroutine that overrides a particular element has to have a special name in general. This specific naming convention provides a clear map for Adams/Solver when it is told that an element has been over-ridden with a user subroutine. An SFORCE element, for example, that specifies a FUNCTION = USER(...) syntax indicates to Adams/Solver that it must look for a subroutine named SFOSUB(). A FIELD element with a USER(...) specification tells Adams/Solver that a FIESUB() subroutine must exist in a user-provided code library.

4. ELEMENT TYPES OVERRIDE (CONT.)
Typical subroutine names include the following:
Statement
Subroutine Name
SFORCE
GFORCE
FIELD
VARIABLE
REQUEST
MOTION
DIFF
SENSOR …
SFOSUB
GFOSUB
FIESUB
VARSUB
REQSUB
MOTSUB
DIFSUB
SENSUB

5. EXAMPLES AND DOCUMENTATION LOCATIONS
The Adams/Solver documentation lists the different subroutines that can be created
See the Adams/Solver guide and navigate to 'User-Written Subroutines' for a list of possible subroutines with descriptions of the element that they override and the implementation
Sample skeleton subroutine implementations are included in the documentation along with links to full implementations from the /solver/usersubs and /solver/c_usersubs directories of your Adams installation
Figure: Subroutine type listing in documentation

6. DETERMINING WHAT TO CALCULATE
Subroutines calculate the values for the particular element that is being overridden. Examples of this:
SFOSUB: returns a single value because an SFORCE has just one value (the force magnitude)
REQSUB: returns eight values, corresponding to the eight components of a REQUEST
GFOSUB: returns six values: the three force and three torque components needed to define a GFORCE
FIESUB: returns either a 6x1 array of values or a 6x6 array of values, depending on whether the FIELD needs to compute its reaction values or whether it needs to compute partial derivatives of its reactions with respect to the displacement and velocity states that influence it.

7. DETERMINING WHAT TO CALCULATE (CONT.)
For each subroutine listed in the ‘User-Written Subroutines’ section of the Solver guide there is an ‘Output Arguments’ section in the documentation
The output arguments always match up with the output values from a standard (non USER()-specified) element in Adams/Solver, so it is a good idea to examine the output from a standard element in Adams/PostProcessor before writing your user subroutine
Figure: Subroutine output definition in the Adams/Solver documentation

8. INPUTS REQUIRED – SUBROUTINE ARGUMENT LIST
There are two distinct ‘input’ sections that must be considered when writing a subroutine, the first is the subroutine argument list
For the subroutine argument list the Adams/Solver documentation provides the 'function prototype' for each subroutine. This lists the variable sequence and types that the subroutine must accept. Adams/Solver will pass all of these variable values into the subroutine during runtime, so the list must match up properly. A subroutine that calculates a VARIABLE value, for example, (the VARSUB) must be named 'VARSUB' and must exactly accept variables of this type with this sequence:
(see next slide)

9. INPUTS REQUIRED – SUBROUTINE ARGUMENT LIST (Cont.)
SUBROUTINE VARSUB(id, time, par, npar, dflag, iflag, value)
Where the variable types are defined in the documentation as:
id: integer variable
time: double-precision variable
par: double-precision array
npar: integer variable
dflag: logical variable
iflag: logical variable
The output variable is ’value’ and it is a double-precision variable as defined in the ‘Output Arguments’ section of the documentation.
Note that the variable input sequence for other elements is similar, but not always the same. Examples:
SUBROUTINE MOTSUB(id, time, par, npar, iord, iflag, value)
SUBROUTINE REQSUB(id, time, par, npar, iflag, result)

10. INPUTS REQUIRED – FROM .adm FILE
The second type of possible input is from an .adm file, in this case the input values are passed in via the element declaration in the .adm file. A typical user-defined SFORCE might have the following declaration in an .adm file:
SFORCE/1, TRANSLATIONAL, I=10, J=11, ACTIONONLY, FUNCTION=USER(120.0,10.1)
The values within the USER() parameter are passed into the PAR variable array during runtime. Each value within the list of the USER() section creates an element in the PAR array and the NPAR variable stores the number of these input values.
In this fashion you can pass in input parameters to your subroutine. For the SFORCE declaration above the values of 120 and 10.1 might represent a spring stiffness and damper constant for a user-defined spring-damper element.
Figure: USER input to PAR array elements

11. PROGRAMMING LANGUAGES
Adams/Solver subroutines can be written in the Fortran or C programming languages
The choice of Solver preference (F77 or C++ Solver choice) does not affect the programming language used; valid subroutines in any language will work with either Solver choice
All documentation has been created for those programming in Fortran. Converting the documentation to C is straightforward. Examples and header file (slv_c_utils.h) exist in the /solver/c_usersubs subdirectory to help create C code. For example a VARSUB declaration in Fortran might look like this:
SUBROUTINE VARSUB(ID, TIME, PAR, NPAR, DFLAG, IFLAG, VALUE)
While the equivalent declaration written in a C source file would look like so:
void Varsub(const struct sAdamsVariable* variable, double time, int dflag, int iflag, double* value)

12. EXERCISE
Perform Workshop 2 “Ejector Mechanism” in your exercise workbook