Simulating
The controlbar is a set of buttons for controlling the simulation. It can be used to start, pause and reset the simulation.
Playing
Click the play button in the controlbar to start the simulation. The dropdown menu allows you to change the speed of the simulation. You can run the simulation either at 0.1x speed, 0.5x speed, 1.0x speed, 2.0x speed or MAX speed. MAX speed will run the simulation as fast as possible, limited only by the speed of your hardware. STEP is used to step between frames, advancing the simulation by a single timestep.
Pausing
After clicking the play button to start the simulation, it will show a pause button. Click this button again to pause the simulation. Click again to start the simulation from where you paused it previously.
Resetting
Click the reset button in the controlbar to reset the model back to its state immediately before the simulation was started:
- Any entities or components that were added during the simulation are automatically removed.
- Any entities or components that were removed during the simulation are automatically added back.
- Any entities or components that were modified during the simulation are automatically reset back to their state immediately before the simulation was started.
This reset behaviour is consistent with reloading a model. It means you don’t need to implement any reset logic inside your scripts and ensures that simulations are deterministic across resets.
What is reset logic?
In most traditional simulation software, you have to implement logic that resets your custom scripts and components back to some initial state. This initial state is sometimes fixed, but frequently you want to be able to specify the initial state.
What is non-determinism?
Non-determinism means that the model may produce different results each time you run the simulation with the same initial conditions. Non-determinism makes models difficult to modify, difficult to reason about and difficult to collaborate on.
Why is reset logic problematic?
Reset logic can be difficult to implement correctly. You typically need to store the values that various properties need to be reset back to, and then reset those properties back to those values when the reset event occurs. Forgetting to reset properties, or resetting properties incorrectly, will introduce non-determinism across reset events. Issues with reset logic are often difficult and time-consuming to track down.
How is reset logic avoided?
Resetting models in ProtoTwin is nearly identical to reloading the model. We store the entire state of the model at initialization (just before the simulation is started) and reload that state when you click reset. This sounds computationally expensive, but we’ve made the effort to ensure that this process is fast even for large models.