Function and Methods

SISAMEM performs multiple-event SISAME modeling, allowing models with matching components to be extracted that provide an optimal, balanced fit to all the events.

Different event types involving different vehicle combinations and speeds can be used together. Vehicles can be matched even if they have some different elements: only the common elements are matched. SISAMEM automatically finds and equates the matching model components.

Features and Options

SISAMEM is driven by a self-documenting ASCII input file that specifies the event information. The SISAMEM input file acts as a master file that identifies the SISAME input files for each event and optionally specifies a weighting factor to control the emphasis on each event.

Any number of events can be included. The events can be of different types (Vehicle-to-Barrier, Vehicle-to-Vehicle, etc.) and can have different speed, filtering, timing, and other specifications. The matching components are identified automatically. Extensive error and warning messages are produced to identify problems in matching the events.

Event-specific outputs are directed to separate event output directories.

Event Matching

SISAMEM finds the matching Vehicle, Mass, and Spring components of each event and equates their corresponding extracted parameters. The component ID and essential structure-defining parameters must agree in two events for a  match to occur. Other parameters, such as those describing the event (e.g., initial velocity), filtering, and target confidence bands need not agree between matched components.

Vehicle matching requirements are fairly loose. Matching Vehicles can have different weights and vehicle makes, models and model years. (Matching Vehicles with different weight values that contain matching extracted-weight Masses may not have feasible weight solutions.) Within matching Vehicles Mass and Spring matching is performed. Matching Vehicles can contain non-matching elements to allow for differences in test instrumentation.

Mass matching requires only that the IDs and weight parameters match. Masses of different Class (Simulated, Target, or Driven) can match each other.

Spring matching requires that the IDs and the static and dynamic behavioral characteristic parameters match (Parameters not affecting the Spring behavior, such as XParMin or ConSS, need not match). The IDs of the attached Masses can differ between the events (a warning message is produced).

Segmented static SE and SI aspects that use automatic tail deflections will prevent Spring matches because the deflection ranges differ, in general. To assure matches, create SISAME input files for each event that use the same defined tail deflections for all SE and SI static aspects in Springs that are intended to match. The largest actual deflection can be found by running each of the SISAME input files in Test mode (with Run Class=T).

Force elements are not matched since they cannot contain extracted parameters.

Parameter matching requires that both parameters have the same value (after any transforms are applied) or that both are extracted or both suppressed. Parameters that reference an extracted parameter can match reference or non-reference extracted parameters, and if both are references the reference targets need not be matching parameters or even present in both events. Two extracted model parameters that were not linked within their event can become linked by the event matching process if they are related by a reference in a matched event. Bounds and estimates need not agree between matching extracted parameters but conflicting bounds will cause the extraction to terminate with a "No feasible solutions" error.

The event matching summary in the master log file should be checked to assure the desired components have been matched. Informational messages document differences between matched components or reasons that components with matching IDs were not matched. Any undesired matches can be suppressed by changing the component's ID in one of the events.

The Input File

The SISAMEM input file has the following format:

SISAMEM Input File

EventID=<EventID>  File=<SISAME_input_file>  [Wtg=<Weighting_factor>]

Comments

The first line must contain  "SISAMEM Input File".

Any number of event specifications can follow, each starting on a new line. Each event specification begins with an EventID=<EventID> field. The <EventID> value is a string of up to ten characters that uniquely identifies the event. The <EventID> defaults to EventE, where E is the sequential event number. The <EventID> is used for the event's output directory name so it should be a valid directory name for the platform.

Each event specification contains a File=<SISAME_input_file> field that identifies the SISAME input file for that event. The SISAME input file need not be located in the <EventID> output directory, so input files in single-event extraction directories can be used directly. SISAMEM finds signal file paths specified in the input files relative to the input file directories, however relative driving force and driven Mass signal file paths in the output model files remain relative to the SISAME input file path and thus such models cannot be simulated from the event output directory.

Each event specification can optionally contain a Wtg=<Weighting_factor> field. The weighting factor, which defaults to one and must be positive, can be used to increase or decrease the extraction emphasis on an extraction event (it has no effect on simulation events). Increasing the weighting for an event will cause the extracted model to fit that event more closely, at the expense of a less accurate fit to the other events.

An optional comments/notes section can follow the event specifications after a line containing just the word Comments. A trailing comment can be added to any line by preceding it with an exclamation point (!).

The events can differ but a few specifications must be the same for all events:

• The Run specifications: MaxIter, ConPC, ConPD, MultPD, Relax, IterCon, and ConvTol
• The Model dimensional system (DimSys)

Setup and Run Instructions

The command line syntax is:  SISAMEM [input_file]

SISAMEM will prompt for an input file if none is specified on the command line.

A master log file for the multiple-event run is created in the SISAMEM input directory containing a summary of the events, the event matching results, and the extracted parameter counts for each event and the combined extracted parameter count after event matching. Extracted parameter counts do not include model parameters that are references to other extracted parameters since these share an internal parameter. Extraction progress messages that apply to the entire multiple-event system and are written to the master log file.

The SISAME output and log files for each event are created in the event output directory named by the <EventID> value. The model summaries in the event log files show the number of extracted parameters in that event, not the total number of extracted parameters after event matching.

Migrating from SISAMEM v.1

SISAMEM v.2 has a few differences from SISAMEM v.1 that affect usage. These include:

• Each event must be specified by a SISAME v.2 input file and is subject to the capabilities/rules of SISAME v.2.
• There is no limit on the number of events (other than the limits of system memory).
• Events with Run Class=T (Test mode) cannot be combined with Extraction events.
• Weighting factors must be positive (comment out events with a ! to get the same effect as a weighting factor of zero).

Known Problems and Constraints

The default equal event weighting will not generally yield the same fit measures for all events since the target equation magnitudes vary between events. Generally, more severe events have larger magnitude target coefficients and thus tend to produce larger fit measures.

Multiple-event extraction iterations may perform more slowly and with poorer convergence behavior than for typical single-event extractions because of a more complex solution space. Additional parameter damping via smaller ConPD and MultPD values may improve the convergence.

Each event is defined by a separate SISAME input file. Some adjustment to ID codes and parameter specifications may be required to achieve desired component matches. For example, automatic tail deflections for segmented static types SE and SI will prevent Spring matches; explicitly specify the maximum deflections over all events for the last X value to avoid this problem.

SISAMEM is intended for extractions from multiple events with some common components. Running SISAMEM with simulation events or extraction events without common components yields the same results as separate SISAME runs.

Additional Documentation

See The SISAME Program: Structural Crash Model Extraction and Simulation for complete SISAME documentation.

A template for the input file can be found in the SISAMEM Input Template.

A history of program changes can be found in the SISAMEM Change Log.