[ACT-R-users] running act-r models of tasks with continuously updating displays

[Jelmer Borst]

While implementing a model of a driving task in ACT-R, I ran into  
trouble with how long it took the model to run: more than a day for a  
single run whereas the participants were finished in about a hour.   
After profiling the lisp code and searching Dan's reference manual for  
a solution, the model now runs in about 5 minutes.

For the ones among you that also want to model tasks with continuously  
updating displays, also run into time problems, and haven't read the  
reference manual, my solution to this problem is provided below.   
(and, maybe someone knows an even better way to do this - Dan?)

Jelmer Borst

---------------------------------------------------
Ph.D. Student
University of Groningen
Department of Artificial Intelligence
Tel: +31 (0) 50 363 6915
Email: jpborst at ai.rug.nl
http://www.ai.rug.nl/~jpborst



When you make an ACT-R model of a ‘standard’ psychological experiment,  
in which the participants perceive some stimulus and have to make a  
response to that stimulus, you probably set it up in the following way:

   1. initiate experiment
   2. display one trial
   3. run model till response is made
   4. goto 2

This works fine for such experiments, however, when you try to model  
an experiment like a driving task in which the display is continuously  
updated, you run into trouble.


The easiest (but VERY slow) way to model such an experiment is to  
change the list above to:

   1. initiate experiment
   2. set-up display
   3. run model for 50 milliseconds
   4. update display if necessary
   5. goto 3

The problem with this is that you call the ACT-R function (run-until- 
time (+ (mp-time) .050)) about every 50 ms. This function not only  
runs the model, but also checks declarative memory (& normalizes chunk  
names etc), actions that only have to be run at the start of a model  
run. These actions significantly slow down your model, to the point  
where it can take a few days to run a model of an experiment that took  
an hour for the human participants to complete.


The solution for this problem is the following:

   1. initiate experiment
   2. set-up display
   3. call (schedule-periodic-event .050 experiment-step :priority :max)
   4. run the model until completion

In step 3 you schedule the function experiment-step to run in ACT-R  
every 50 ms (experiment-step is the function of the experiment that  
updates the display). Basically, what happens now is that the model  
runs continuously, but calls the function experiment-step every 50 ms.  
This way the ACT-R run function is only called once, which eliminates  
a lot of unnecessary calls to DM. The result is that the model now  
runs in ~5 minutes.


Dan says it this way in the reference manual:

The event system that drives ACT-R models is also available to the  
modeler for use in writing
experiments or “driver code” for the models.  In fact, because ACT-R  
relies on the events to trigger
actions such as conflict-resolution, this is the preferred mechanism  
for creating experiments or
making other run-time changes.  It is also essential when adding new  
modules to schedule events to
affect any changes which the module has on buffers as well as when  
changing its internal state or
affecting outside actions.

When writing experiments for a model, one useful approach is to have  
the model’s actions trigger the
events that make changes in such a way that one only needs to call one  
of the ACT-R “run” functions
to execute both the model and the task.  That has the benefit of not  
introducing any discrepancies into
the model timing relative to the task and also allows for the task to  
be run using the provided stepping
tools or continued after a break in the model.  That is not always  
practical for a simple model/task
and often one may want to use a run, stop, change, run again style.   
When using the run-stop style, it
is still important to schedule any direct effects that one makes to  
buffers or chunks so that the model
properly notes the changes.