1. ODB MPDB Model Setup and Boundary Condition Verification
Baseline ODB MPDB Model Setup
This case establishes a runnable baseline for the ODB (Offset Deformable Barrier) MPDB (Mobile Progressive Deformable Barrier) frontal crash simulation. The objective is not to produce injury numbers yet, but to confirm that the solver environment, model assembly, and boundary conditions are physically consistent before any dummy or restraint work begins. A short verification run (typically 20–50 ms of simulated time) is used to detect gross errors such as missing contacts, incorrect initial velocity, barrier misalignment, or ground penetration.
The ODB MPDB configuration differs from a rigid-wall full-width test in three important ways: the barrier is a deformable honeycomb-faced trolley that moves with the vehicle, the impact is offset (typically 40% overlap on the driver side), and the vehicle is propelled toward the barrier rather than into a fixed wall. These differences drive the boundary condition set described below.
Model Assembly and Coordinate Convention
Before applying any boundary conditions, fix the global coordinate system and document it. A consistent convention for this course is:
- X axis: longitudinal, positive toward the front of the vehicle (direction of travel).
- Y axis: lateral, positive toward the driver side (left-hand drive).
- Z axis: vertical, positive upward, ground plane at Z = 0.
All positions, velocities, and barrier offsets in this case use this convention. If your model uses a different sign convention, translate the values before applying them and note the change in the model log.
The assembly consists of the vehicle model (BIW, closures, suspension, powertrain as rigid or deformable parts), the ODB trolley with its deformable barrier face, and the ground plane. The barrier face centerline must be offset laterally so that the overlap with the vehicle front structure matches the target ODB MPDB overlap. For a 40% offset on a vehicle of width W, the barrier centerline is placed at Y = +0.20·W relative to the vehicle centerline (driver side), assuming the barrier is narrower than the vehicle. Verify this against your barrier face width before running.
Boundary Conditions
Apply the following boundary conditions as a minimum set. Values below are teaching example parameters; substitute your project-specific test speed and mass where required.
| Boundary condition | Object | Example value | Notes |
|---|---|---|---|
| Initial velocity | Vehicle (all nodes) | +16.0 m/s along X | Applied as initial velocity, not a prescribed motion |
| Barrier velocity | ODB trolley | 0 m/s (stationary) or matched per test protocol | Confirm whether the barrier is fixed or moving in your test definition |
| Ground | Rigid plane at Z = 0 | Friction μ = 0.7 | Prevents wheel drop-through; check tire contact |
| Gravity | Global | −9.81 m/s² along Z | Required for suspension and dummy settling |
| Barrier constraint | ODB trolley | Fixed translation in Y and Z, free in X | Allows barrier to be pushed rearward on impact |
Apply the initial velocity to the vehicle as a nodal initial velocity condition rather than a prescribed displacement. A prescribed motion will over-constrain the structure and produce non-physical forces at the firewall. Confirm that the velocity is applied to all vehicle nodes, including suspension and unsprung mass, so the model translates as a rigid body before impact.
*INITIAL_VELOCITY and *BOUNDARY_PRESCRIBED_MOTION, use the former for the vehicle and reserve the latter for the barrier trolley if the test protocol requires a moving barrier.Verification Run and Integrity Checks
Run the model for a short duration (20–50 ms) with a stable explicit time step. The purpose is to observe pre-impact behavior and the first contact, not to complete the crash. Check the following:
- Energy balance: hourglass energy should remain below roughly 5% of total energy; if it grows rapidly, review element formulation and contact stiffness.
- Initial penetration: query contact penetrations at t = 0. Any positive penetration between barrier face and vehicle front indicates a geometry or offset error.
- Velocity consistency: confirm the vehicle center of mass velocity matches the applied initial velocity within numerical tolerance before contact.
- Ground contact: verify tires rest on the ground plane without initial penetration or lift-off.
- Barrier alignment: confirm the barrier face centerline offset matches the intended overlap and that the barrier is square to the vehicle.
Typical failure symptoms and their likely causes: a sudden spike in contact force at t = 0 usually means initial penetration; a rapid drop in kinetic energy before impact suggests an over-constrained boundary; hourglass energy growth points to under-integrated elements or missing contact stiffness. Address these before proceeding to dummy positioning.
Interpreting the Verification Output
If all five checkpoints pass, the model is ready for dummy positioning and restraint routing in the next stage. If any checkpoint fails, resolve it before adding complexity. A common mistake is to proceed with a small initial penetration because the run "looks fine" — this penetration will bias the contact force history and corrupt later injury metrics. Treat the verification run as a gate, not a formality.
Baseline Configuration Record
Record the following in the model log so the baseline is reproducible and comparable across the 100-case series:
- Coordinate convention and sign of X, Y, Z.
- Vehicle mass, initial velocity, and barrier offset value used.
- Ground friction coefficient and gravity vector.
- Barrier constraint definition (fixed axes, free axes).
- Verification run duration, time step, and the five checkpoint results.
With this record in place, subsequent cases can reference a known-good baseline and isolate the effect of dummy, belt, and contact changes on injury response.