Processing in a COGENT model involves all of the individual boxes or modules sending data to each other along the arrows that connect them. Processing occurs in cycles, with each cycle having two phases. In the first phase, data is sent along the arrows. We'll see below where this data comes from. In the second phase, the data received by each box is processed according to the processing characteristics of the receiving box. Within each phase, all boxes are processed in parallel. The goal of this section of the tutorial is to run our first model, thus clarifying this execution model.
To run the classification model select Trial from the Run menu button at the top of the model's main window (i.e., the one containing the box/arrow diagram). A window like the following will appear:
The run window has a series of buttons on the top which control the model's execution. Beneath this is a small region in which execution commands will appear when the buttons on the top line are pressed. The contents of this section of the window can generally be ignored. The lower portion of the window contains the output trace. This is where output and error messages that arise during the model's execution appear.
We have selected Trial mode from the Run menu. This mode is appropriate for stepping through the individual cycles of a single "trial". COGENT also provides a Block mode, for execution of blocks of multiple trials (paralleling the way that, in many experiments, subjects perform blocks of multiple trials). For present purposes we are only concerned with the Initialise and Step buttons. The Initialise button initialises execution by loading the model's specification into the execution engine. Press this button and you should see a message in the output trace window confirming that initialisation is taking place. When initialisation is complete, press the Step button a number of times, until the message All data processed appears in the output trace. The execution window might now look something like:
Each time you press the Step button, the execution model performs one cycle of processing. Recall that communication between boxes is based on passing messages between boxes (via the arrows). On each cycle, processing involves sending any current messages down the arrows to their target boxes, and then processing those messages when they arrive. Often, this processing will result in new messages being generated. These are stored up ready for sending (and processing) on the next cycle.
When our classification model is initialised, the only current message is the first element in Test Cases, which is waiting to be sent to Classification Rules. When Step is pressed, this message is removed from the source and fed to the process. You can see this happen if you open Test Cases (by double-clicking on its icon within the box/arrow diagram) and set its Mode to Message Log. Watch the messages appear in the log as you Step through processing in the run window. You might like to repeat the exercise with the Mode of Test Cases set to Current Contents. You will see the contents of the data source gradually disappear as they are fed down the arrow to Classification Rules.
You can also examine the processing of Classification Rules by opening it in Message Log mode. The following figure shows Classification Rules after the first cycle.
Note that here, messages are received and generated on the same cycle. The message spider is received from Test Cases, and processed to yield the message vertebrate which is to be sent to Output. This generated message isn't actually received by Output until the second cycle. This is indicated by the line:
2: Output invertebrate
in the output trace.
There is no Current Contents mode for rule-based processors because the contents of a process cannot change. The contents of buffers, on the other hand, can. In this first version of the model we have specified the initial contents of the two buffers, but we have not specified any buffer modifications. Thus, viewing the Current Contents of the buffers is not particularly entertaining. In models where buffer contents do change, however, the Current Contents view of buffers provides a clear picture of the changes that occur throughout processing, and the Message Log view allows the user to see why those changes occur.
By default, pressing Step causes a single cycle of processing. This default behaviour can be altered by setting an alternate value for Cycles/Step*. It is also possible to run a complete trial by using Block mode. This can be selected by either using the Mode menu button on the run window, or by selecting Block from the Run menu of the model's main window.
In Block mode, you'll notice that there is no Initialise button. This is because the execution engine automatically reinitialises on each press of the Run button. You may also notice that it is possible to run a block of multiple trials, by setting Trials/Block* to be greater than 1. There is little point in doing this with the current model (though you might like to try running of block of, say, 5 trials), because it is entirely deterministic. If our model employed components with nondeterministic behaviour, however, then different trials could produce different behaviour. In such cases, running multiple trials is necessary in order to get a true picture of the model's behaviour.
*Beware of using the increment/decrement buttons to alter the value of Cycles/Step and Trials/Block as they may trigger a bug in the windowing environment.