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

[Dan Bothell]

That's a nice description of the issue and solution and there's
not much I have to add to it.

One thing to note is that those different methods for setting up the
experiment code are also described in the auxiliary text for unit
4 of the ACT-R tutorial.  The zbrodoff model for that unit uses a
similar "one call to run" style for those that want to see a full
example.  However, it does differ slightly from Jelmer's in that it
doesn't have the periodic updating.  It only transitions on the
model's key-press events.

Also, the most likely cause of the long run times in the first
version of the task was the setting of the :ncnar parameter.  The
default value of t is a real killer when there are lots of calls
to run or of the model runs for a "long" time.  Setting that
parameter to nil usually helps quite a bit in those situations.
That is described in the main text for unit 4 of the tutorial.
For the paired associate model from that unit, leaving :ncnar
at t causes the model to take about 10x as long to run.  The
addition and default value of that parameter were also noted
in the change log.

Everybody checks the log when they get a new version, right? ;)

Dan


--On Friday, January 18, 2008 2:19 PM +0100 Jelmer Borst 
<J.Borst at ai.rug.nl> wrote:

> 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.
>
> _______________________________________________
> ACT-R-users mailing list
> ACT-R-users at act-r.psy.cmu.edu
> http://act-r.psy.cmu.edu/mailman/listinfo/act-r-users
>