4. MADYMO model setup fundamentals

Before any restraint system or occupant can be simulated, the input deck must be assembled correctly. MADYMO does not read a single monolithic file; it reads a main input file that references a set of include files, each holding one logical block of the model. Understanding this structure, the XML syntax that expresses it, the unit conventions, the coordinate systems, and the initialization sequence is what separates a model that runs from a model that silently produces nonsense.

4.1 The Input Deck as a Tree of Files

A MADYMO input deck is a hierarchy. The main file (conventionally main.xml or model.xml) contains the top-level <MADYMO> element and pulls in everything else through include directives. Typical decomposition for a frontal occupant model looks like this:

model/
├── main.xml              # top-level control, includes everything
├── units.xml             # unit system declaration
├── systems/
│   ├── vehicle.xml       # vehicle body, seat, belt anchors
│   ├── dummy_hybrid3.xml # Hybrid III 50th percentile FE/MB model
│   └── belt.xml          # FE seatbelt, retractor, pretensioner
├── contacts/
│   └── contact.xml       # contact definitions between systems
└── control/
    └── simulation.xml    # time step, output interval, termination

The main file then reads:

<?xml version="1.0" encoding="UTF-8"?>
<MADYMO version="7.7">
  <INCLUDE file="units.xml"/>
  <INCLUDE file="systems/vehicle.xml"/>
  <INCLUDE file="systems/dummy_hybrid3.xml"/>
  <INCLUDE file="systems/belt.xml"/>
  <INCLUDE file="contacts/contact.xml"/>
  <INCLUDE file="control/simulation.xml"/>
</MADYMO>

Include paths are resolved relative to the directory of the file that contains the <INCLUDE> element, not relative to the working directory. This is the single most common source of "file not found" errors when a deck is moved between machines. Keep the directory tree intact, or convert to absolute paths only for debugging.

4.2 XML Syntax Rules That Matter

MADYMO input is strict XML. Every element must be closed, attribute values must be quoted, and the document must have exactly one root element. Three rules cause most beginner failures:

• Case sensitivity. <SYSTEM> and <system> are different elements. MADYMO keywords are conventionally uppercase; element names follow the schema.
• Attribute vs. child element. Scalar parameters are attributes (<INITIAL.VELOCITY vx="0" vy="0" vz="-50"/>); structured data are child elements. Mixing them up produces a schema validation error, not a runtime error.
• Comments. Use <!-- ... -->. A comment cannot contain -- inside it.

When a deck fails to parse, MADYMO reports the line number and the offending token. Read the error literally: it usually points at the exact attribute that is malformed, not at the logic of the model.

4.3 Units: Declare Once, Obey Everywhere

MADYMO is unit-agnostic in the sense that it does not enforce a system, but it is not unit-free. You declare a consistent set in the <UNITS> block, and every numeric value in the deck is interpreted in those units. The recommended SI-adjacent set for occupant safety work is:

The trap is angles. MADYMO expects radians in the input deck, but most CAD and test data arrive in degrees. A belt anchor specified as angle="45" when you meant 45° becomes 45 rad — roughly 2578° — and the belt will wrap in a physically impossible way. Convert explicitly: 45 * pi/180 = 0.7854. Declare the conversion in a comment so the next engineer can audit it.

4.4 Coordinate Systems and Sign Conventions

MADYMO uses a right-handed Cartesian system. The convention that matters for occupant safety is the vehicle coordinate system: X forward, Y to the left, Z up. Gravity acts in the negative Z direction. A frontal crash pulse is therefore a negative X acceleration applied to the vehicle body.

Each <SYSTEM> can carry its own local frame, defined by an origin and an orientation relative to its parent. The dummy is typically placed as a child of the vehicle system, with its own local origin at the H-point. When you specify joint angles or initial positions, you are working in the local frame of that system, not the global frame. This is the second most common source of "the dummy is in the wrong place" errors.

To keep the deck auditable, adopt one rule and state it in a comment at the top of main.xml:

<!-- Convention: global X forward, Y left, Z up. Gravity = -Z.
     All angles in radians. All lengths in metres. -->

4.5 Model Initialization Sequence

Initialization is not a single command; it is the ordered resolution of the deck. MADYMO processes the tree in this order:

1. Parse and validate the XML against the schema. Errors here stop the run before any physics.
2. Resolve includes depth-first, building the complete element tree in memory.
3. Apply units from the <UNITS> block to all numeric attributes.
4. Instantiate systems — each <SYSTEM> becomes a rigid or flexible body with its local frame.
5. Resolve contacts between systems, building the contact pair list.
6. Set initial conditions — velocities, positions, belt slack, pretensioner state.
7. Enter the time integration loop at t = 0.

The practical consequence: if the dummy appears at the wrong location at t = 0, the fault is in steps 4–6, not in the solver. Check the local frame origin and the initial position attributes before touching the time step.

4.6 A Minimal Working Deck

The following is a complete, runnable skeleton for a single rigid body falling under gravity. It is deliberately small so every element can be inspected. Use it as a template when starting a new model.

<?xml version="1.0" encoding="UTF-8"?>
<MADYMO version="7.7">
  <UNITS length="m" mass="kg" time="s" force="N" angle="rad"/>

  <SYSTEM name="body">
    <INITIAL.POSITION x="0" y="0" z="1.0"/>
    <INITIAL.VELOCITY vx="0" vy="0" vz="0"/>
    <BODY mass="1.0">
      <INERTIA ixx="0.01" iyy="0.01" izz="0.01"/>
    </BODY>
  </SYSTEM>

  <CONTROL>
    <SIMULATION t_end="0.5" dt="1e-4" output_interval="1e-3"/>
  </CONTROL>
</MADYMO>

Run it and inspect the Z position at t = 0.5 s. With g = 9.81 m/s² and no initial velocity, the body should have fallen approximately 0.5 × 9.81 × 0.5² = 1.23 m. If the reported displacement is off by a factor of 1000, the length unit is wrong. If it is off by a factor of 57.3, an angle was misinterpreted. If the body does not move at all, gravity was not applied — check that the <GRAVITY> element is present and that its direction is -Z.

4.7 Practical Checklist Before the First Run

• Does main.xml have exactly one <MADYMO> root element?
• Is the <UNITS> block present and consistent with every numeric value in every include?
• Are all angles in radians, and is the conversion documented?
• Is the global frame convention (X forward, Y left, Z up, gravity −Z) stated in a comment?
• Does each <SYSTEM> have a defined local origin, and is the dummy placed relative to the correct parent?
• Are include paths relative to the including file, not the working directory?
• Is t_end long enough to capture the event, and is dt small enough for contact stability (typically 1e-4 to 1e-5 s)?

With the deck structured, units declared, frames defined, and initialization verified at t = 0, the model is ready for the contact and restraint definitions that follow. The discipline of building and validating the skeleton first is what makes the later, more complex stages tractable.