C. Control the simulation

The simulation advances in iterations. An iteration has passed when all agents have had on average one opportunity of interaction (i.e. an agent transmitting a trait to another agent). The number of opportunities to interact is the same as the number of agents in the system, however, not necessarily all agents receive an opportunity in each iteration, because agents are selected randomly for interaction. Additionally, agents might reject the interaction for several possible reasons outlined in the rules of each model (See B. Initial Parameters), which is why we call it a number of opportunities, and not a number of interactions, per iteration.

Progress of the simulation is not registered by iteration, instead, there are checkpoints. A checkpoint occurs per every s iterations. The parameter for s is Speed. We have also covered how to set the value for Speed in the chapter on B. Initial Parameters).

Checkpoints

During a Checkpoint, all the following steps occur:

1. Response Variables are calculated according to the current state of the simulation.
2. Response variables are sent to the progression output file(s).
3. Cultural Panels, Graphs and Status Bar are updated with the current results.
4. The simulation checks for current queued Events and executes them, if any.
5. The simulation checks if the simulation has been paused via the Pause Button

Main Controls

The Main Controls of the simulation are in the top-left corner of the interface. Controls can also be found in the in the Controls menu.

From this bar, you can start the simulation via the Play Button and stop it via the Stop Button or the Pause Button . However, there are a few important things to consider when using the latter two:

• Their actions will take effect only at a checkpoint. Depending on the speed parameter, you might have to wait until their effects are processed.

• The main difference between pausing and stopping the simulation is that stop will store final file results. When the Play Button is pressed after you have stopped the simulation, a new result folder will be generated in the workspace (see Output Files for details). Pause is non-intrusive. It freezes the simulation without further implications. Pausing also does not allow saving or reloading simulation states. Visually, there is no difference between Pause and Stop.

The two last buttons (both yellow) in the main control area are straightforward. You can save the current state of the simulation by clicking the Save State Button . You can also save this state as a file by clicking on File -> Save Simulation State. After the simulation runs for some iterations, you can go back to a previously saved state, by pressing the Reload Simulation Button (or reload a previously saved file with File -> Load Simulation State).

One use of these two buttons is that the Saved State can become the state against which the progressing state of the simulation is compared, for example to compare how similar the results of Saved State and Current State are at any given moment. You can read further on this topic in the chapter on Response Variables. The response variables of both states, saved and current, can also be observed in the Status Bar at the bottom of the interface (blue font), while the Graphs are useful to note visual changes in the progression. A quick guide for this process is provided at the end of the Quick Start chapter.

Simulation states files

Apart from saving and reloading a state on memory with the Save State Button , it is possible to save a state in a file with File -> Save Simulation State and then recover it via File -> Load Simulation State. This can be useful for several things:

• Multiple saved files can be stored and accessed successively to compare many different Events.

• It is possible to run multiple instances of the program, loading different files in each one.

• Saved State files can be opened in the parameters dialog (See Setting Up Initial Parameters).

• Saved State files can be used to run simulations in Batch Mode.

Controlling Speed

Right below the Main Controls, you can find the Speed Bar:

The Speed Bar controls the simulation speed via reduction or increase of the frequency of updates on the screen. Lower values cause the simulation to run for a longer time span, as updates are provided more often. The value next to the Speed label (set at 100 in the above figure) shows how many iterations have to pass in order for a checkpoint to occur. Review Checkpoints here.

Events are always added to the simulation at a checkpoint and visualized in the interface. When we change the speed via speed bar, updating the variable might take some time. The results file for the current simulation will also be affected because results are sent during checkpoints. Due to changes in speed, results will not be stored in regular intervals.