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')
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.
See Also
Improving Speed and Accuracy | Reduce Zero Crossings | Examine Model Dynamics Using Solver Profiler