4. Preparing MADYMO input decks for batch execution

On a Linux HPC cluster, a MADYMO run is only as reliable as the input deck that feeds it. Interactive GUI workflows tolerate loose file organization because the operator is present to fix paths and re-select files. Batch execution does not. Once a job is submitted through a scheduler, the solver reads the deck, resolves every reference, and either runs to completion or fails with a message buried in a log file. This section covers how to structure MADYMO XML input for unattended execution: the XML document layout, how include files are resolved, how model units are declared and kept consistent, and how to organize a model directory so that hundreds of concurrent jobs do not collide.

XML Input Structure

A MADYMO input deck is an XML document whose root element is <MADYMO>. Inside it, the model is described by a small number of top-level sections that map directly onto the physical model: <UNITS>, <SYSTEM> blocks for multibody and finite element parts, <CONTROL> for solver settings, and <OUTPUT> for what the run writes to disk. A minimal but complete deck looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<MADYMO version="7.7">
  <UNITS length="m" mass="kg" time="s" angle="rad"/>
  <CONTROL>
    <TITLE>Sled_Frontal_50kmh</TITLE>
    <RUN> time_end="0.120" />
  </CONTROL>
  <INCLUDE file="model/vehicle_body.xml"/>
  <INCLUDE file="model/dummy_hybrid3.xml"/>
  <INCLUDE file="model/belt_system.xml"/>
  <OUTPUT>
    <MATRIX file="results/kinematics.xml"/>
  </OUTPUT>
</MADYMO>

The version attribute on the root element is not decorative. It tells the solver which schema to validate against, and a mismatch between the declared version and the installed solver is one of the most common causes of a job that parses cleanly on a workstation but aborts on the cluster. Pin the version explicitly and keep it identical across all decks in a study.

Two structural rules matter for batch work. First, element order inside <MADYMO> is significant: <UNITS> must appear before any geometry, and <CONTROL> before the systems it governs. Second, every element that references an external file — <INCLUDE>, <MATRIX>, <FEMESH> — should use a path that is valid from the job's working directory, not from the directory where the file happens to sit.

Include Files and Path Resolution

Include files are the primary mechanism for reusing submodels across a study. A vehicle body, a restraint system, or a dummy definition can live in its own XML file and be pulled into many decks. The critical question for batch execution is: relative to what directory is the file attribute resolved?

MADYMO resolves relative include paths against the directory of the including file, not the process working directory. This is convenient for nested includes but dangerous when a deck is copied to a cluster node without its directory tree. The robust pattern is to keep the include tree intact and submit the job from the directory that contains the top-level deck:

project/
  run_frontal.xml          <-- top-level deck, submitted to scheduler
  model/
    vehicle_body.xml
    dummy_hybrid3.xml
    belt_system.xml
  results/                 <-- created by the job, or pre-created

With this layout, <INCLUDE file="model/dummy_hybrid3.xml"/> resolves correctly regardless of where the scheduler starts the process, because the path is relative to run_frontal.xml. Avoid absolute paths such as /home/user/project/model/... in shared decks: they break the moment the study is archived or moved to a different cluster. If a path must be configurable, generate the top-level deck per job from a template rather than editing includes by hand.

Model Units

The <UNITS> element declares the unit system for the entire model. MADYMO does not convert values; it interprets every number according to the declared units. The four attributes are length, mass, time, and angle. A consistent SI-style declaration is:

<UNITS length="m" mass="kg" time="s" angle="rad"/>

Two failure modes dominate. The first is a silent unit mismatch: a submodel authored in millimetres is included into a deck declared in metres, and the resulting geometry is a thousand times too large. The solver may still run, producing nonsense accelerations that are only caught during post-processing. The second is an angle-unit mismatch: restraint pretensioners and belt routing are frequently specified in degrees, but if angle="rad" is declared, a 30-degree wrap becomes 30 radians. Declare the angle unit explicitly and document it in the model header comment.

Because units are global, the safest practice is to fix one unit system for an entire project and state it in a comment at the top of every deck. When a legacy submodel uses different units, convert it once at the source rather than mixing systems in the top-level deck.

Cluster-Friendly Model Organization

On a shared cluster, the dominant risk is not a single bad deck but interference between concurrent jobs. Three practices prevent it.

• One job, one working directory. Each submitted job should run in its own directory, typically created by the scheduler or by a wrapper script. Never let two jobs write results/ in the same location.
• Read-only shared model tree. Keep the model/ directory on shared storage with read-only permissions for the run account. Jobs read includes from it but never write back, so a corrupted run cannot damage the source model.
• Explicit output paths. Point <OUTPUT> at a job-local directory. Relative output paths are resolved against the process working directory, which the scheduler controls, so make the intent explicit in the deck or in the submission script.

A practical submission wrapper makes the contract concrete:

#!/bin/bash
#SBATCH --job-name=madymo_frontal
#SBATCH --nodes=1
#SBATCH --ntasks=8
#SBATCH --time=04:00:00

module load madymo/7.7
cd "$SLURM_SUBMIT_DIR"
mkdir -p results
madyamo -f run_frontal.xml -n 8 > madymo.log 2>&1

The cd "$SLURM_SUBMIT_DIR" line is what makes relative include paths deterministic. Without it, the scheduler may start the process in a spool directory and every include will fail to resolve.

Verifying a Deck Before Full Submission

Before committing cluster hours, validate the deck cheaply. Run a short-duration job — set time_end to a few milliseconds — and inspect the log for parse errors, unresolved includes, and unit warnings. A clean parse with a completed short run confirms that the XML structure, include tree, and unit declarations are consistent. Only then extend time_end to the full event duration.

The diagram summarizes the contract: the top-level deck declares units and control, includes resolve against the deck's own directory, outputs land in a job-local directory, and a short validation run gates the full submission. Treating these as fixed conventions rather than per-job decisions is what makes a MADYMO study reproducible across a cluster.