The general probe is a combination two tools that provides a general capacity to track arbitrary parameters over time. On the runtime side, org.jactr.tools.grapher.core.GeneralProbe selects model elements (productions, chunks, types, modules, buffers, etc), based on regular expression name matches (quick and easy to implement, but a little wonky if you don't know reg-ex), and attaches probes to them. The general probe then sends that data to the IDE where it is rendered in the jACT-R Probes view.  

Probe Configuration

GeneralProbe reads a user specified probe descriptor file that defines what model elements should be tracked and what parameters recorded. These probe files are usually stored within the configuration/ directory so that it is accessible on the classpath. The following is a useful template for building your own custom probes:

<!-- how frequently should we poll the probes (seconds) -->

<instrument window="1">

<!-- probes can be grouped together so that they share a common axis -->

<group id="harvestors">

<!-- this will just select a model named 'sub', .* will select all -->

<model pattern="sub">

<!-- harvest productions -->

<!-- just probe productions with '-harvest' at the end -->

<production pattern=".*-harvest">

<!-- just record the expected utility -->

<probe pattern="ExpectedUtility" poll="true" />

</production>

</model>

</group>

</instrument>

You can also probe chunks:

<chunk-type pattern="configural">

<chunk pattern="configural-.">

<probe pattern="BaseLevelActivation" poll="true"/>

</chunk>

</chunk-type>

The above will only probe configural chunks that match the name 'configural-?'. The chunk-type tag is optional.

Modules can also be probed:

<module pattern=".*Retrieval.*">

<probe pattern=".*Threshold" poll="true"/>

</module>

Using probes

Once the probe file is defined, you merely have to enable it in the run configuration. Merely enable General Probe in the Logging/Trace tab of the run configuration and provide it the probe file.

As the model runs, the probes view will graph the values over time. The graphs aren't good enough for publication, but as a first pass monitor, it's value cannot be overstated. You'll understand immediately why a production is loosing out in conflict resolution or a chunk is failing to be retrieved.

The viewer also has two export options: PNG image file or CSV data output.

The IDE supports the saving and replaying of runtime data. Specifically, on the Logging/Trace tab of the run configuration you can select to send tracer data to IDE and/or file (but at least one). This data will be saved to a folder named sessionData. Right clicking on this folder in the IDE will give you the option jACT-R->Playback. You can then step through the data in the log view or probe viewer.

Caution: Session data can consume a large amount of space. Clean up after yourself.

To help debug models that rely upon the visual system, jACT-R includes a graphical visicon viewer. It's a little rough around the edges right now, but it is certainly functional.

Using Visicon Viewer

To use, simply enable the visicon tracer in the run configuration for your model. Once the model starts, the visicon viewer (lower-left corner of the IDE) should be updated.

Currently the color coding is used to signal search and encoding results. A red border means the object there has been found, a solid red means it is the current focus of attention. If you mouse over the object you will see a listing of its primitive features.

Future updates will include better formatting of the information.