Analyze Tradeoffs Between Performance and Fidelity

When designing physical system models, you must balance how the model performs and the amount of detail in the model. Increasing the fidelity of your model also increases the computational requirements. You can improve performance by omitting some physics or lumping parameters as long as the results still meet your criteria.

Fast models are useful when you are in the early stages of design and need to rapidly iterate and when you need to integrate your simulation with hardware-in-the-loop (HIL) processes. These models prioritize computational efficiency, which allows for faster simulation times and more seamless integration with hardware systems. High-fidelity models use more computational resources to capture physical detail with more accurate results. High-fidelity models may not be suitable for HIL because they require more resources than the target hardware can supply. For HIL applications, the solver speed requirements depend on the target hardware.

Simplify a Model for Better Performance

You can make a model perform faster by avoiding elements that cause discontinuities or fast dynamics. Elements such as hard stops or backlash, stick-slip friction, and clutches are prone to discontinuities. Small masses connected to stiff springs without sufficient damping can cause fast system dynamics that increase the computation cost for a time step. To see a model that you can configure for performance or high-fidelity, open the Vehicle with Four-Wheel Drive model. Enter:

openExample('sdl/VehicleWithFourWheelDriveExample')

This model uses the Generic Engine block, labeled Engine, to provide torque to the system. The Torque Converter block acts as a damper between the engine and the Simple Gear block labeled Gearbox. The torque transfers from the block, labeled Gearbox block to both Differential blocks. The four tire blocks convert the rotational energy into translational energy to propel the Vehicle Body block, which calculates the interactions between the tire and the road surface.

The four tire blocks are Variant Subsystem blocks that contain three tire variants. Each variant uses a different block to represent the tire dynamics. Double-click the Left Front subsystem to see the active and inactive variants. To learn more, see Variant Subsystem, Variant Model, Variant Assembly Subsystem.

Double-click each variant to see the different implementations.

The default implementation uses the Tire (Magic Formula) block, which calculates the tire using slip angle, longitudinal slip, and vertical load. This block results in high-fidelity calculations, but the model slower to simulate than the other two implementations. The Simple subsystem uses the Tire (Simple) block, which results in a faster model and lower fidelity tire calculations. The Tire (Simple) blocks represent a simple, no-slip model.

To enable the Simple variant on all four tires, click the Simple hyperlink in the top model or enter:

VehicleWithFourWheelDriveSetTires(bdroot,'simple')

The subsystem icons indicate which implementation they use.

To confirm that the Gearbox, Front Differential, and Rear Differential blocks are configured for speed, check that Friction model is No meshing losses - Suitable for HIL Simulation. Also confirm that Enable backlash is cleared for the Simple Gear block. The model is now less complex and can run faster than the default model.

To run the faster model to collect data and plot the time step information, enter:

sim('VehicleWithFourWheelDrive')
simlogRef = simlog_VehicleWithFourWheelDrive;
tireRefNode = simlogRef.Left_Rear.Simple.Tire_Simple.A.w;
tRef = tireRefNode.series.time;
semilogy(tRef(1:end-1),diff(tRef),'-x')
title('Solver Step Size')
xlabel('Time (s)')
ylabel('Step Size (s)')
legend('Simple Tire',location='best')

The spike that happens one second into the simulation indicates the presence of an event that requires the solver to take a smaller time step.

Visualize the Difference Between Performance and Fidelity

Now that you have baseline results using a simple implementation of the model, you can analyze the performance improvement over the default model. Switch the tire variants back to the Tire (Magic Formula) block, run the simulation, and plot the results.

VehicleWithFourWheelDriveSetTires(bdroot,'MFormula')
sim('VehicleWithFourWheelDrive')
simlogRef = simlog_VehicleWithFourWheelDrive;
tireRefNode = simlogRef.Left_Rear.Magic_Formula.Tire_Magic_Formula.A.w;
tRef = tireRefNode.series.time;
hold on
semilogy(tRef(1:end-1),diff(tRef),'-o')
legend('Simple Tire','Magic Formula Tire',location='best')

The denser grouping of time steps at the beginning of the simulation indicates that the model takes longer to initialize. After the first spike at one second into the simulation, the solver reaches a second spike with a slow recovery. Compared to the simple tire implementation, the solver takes extra resources to compute the results. The smaller step sizes are the result of capturing additional physical behavior in the simulation. The high-fidelity implementation captured an event at about 1.2 seconds that the simple tire implementation did not. Zoom in on the results to get a better view.

Also, at around eight seconds, the high-fidelity implementation shows an event that occurs later than in the simple implementation.

The high-fidelity model captures more detailed and more accurate results but takes longer to simulate and takes smaller solver steps. You can gain more detailed insights about the simulation by using the Solver Profiler. To learn more about solver step size and real-time model preparation, see Determine Step Size.