PXLab Manual

[Home]    [Content]    [Previous Chapter]    [Next Chapter]


The Experimental Procedure

The Procedure() section of an experimental design file controls the sequence of sessions, blocks, and trials and also controls the assignment of experimental conditions to subject groups. It starts with a declaration possibly containing a list of argument values and has one or more session blocks following it. Here is an example from the PXLab lab course:

  Procedure()
  {
    Session()
    {
      Block( 1, 0)
      {
        Trial( ?, 2, ?);
        Trial( ?, 90, ?);
      }
      Block( 2, 1)
      {
        Trial( ?, 2, ?);
        Trial( ?, 90, ?);
        Trial( ?, 2, ?);
        Trial( ?, 90, ?);
      }
    }
  }

We have one Session() statement and this contains two Block() statements. The first block contains two Trial() statements and the second block contains four Trial() statements.

Arguments of Procedure Units

The arguments of the Procedure()Session(), Block(), and Trial() statements are defined by the respective display list definitions in the Context() section. In our example the arguments for these display list objects are:

    Session() {
      ...
    }

    Block( BlockCounter, StoreData) {
      ...
    }

    Trial( TrialCounter, Luminance, ResponseTime) {
      ...
    }

The arguments of a procedure unit define those experimental parameters which should be localized to the respective procedure unit. Parameter names given in these definitions must be known parameters, either by being known to the system or by having been created by a previous new-statement or a previous factor definition. In our example the parameters BlockCounter and StoreData are local to each block. Every parameter has a global value. Local parameters are by default initialized to their global values. However, after changing the value of a local parameter, their global value is no longer accessible from within that block which defined the parameter as local. In our example the parameter StoreData may have a global value of 0. If the later Block() call sets the value of StoreData to something different, then the original global value is no longer accessible within this Block(). After leaving the Block() the global value is accessible again. This same mechanism is used for all data collection units.

One may also think of local parameters as those parameters which can change their value for every session, block, or trial respectively while any other parameter remains constant. This also means that the local parameters within a procedure unit do and can not propagate their values to the next unit of the same type. Thus in our example we have a local Luminance parameter in every trial. The Luminance value in any trial has no influence on the luminance value in the next trial. There is, however, a mechanism to explicitly propagate parameter values to consecutive trials or blocks which we will discuss later.

The arguments of each data collection unit are parameter values or parameter names. The parameter values become the parameters' values used in the scope of the respective data collection unit. The scope of a data collection unit is the set of sub-units which are contained between the unit's curly braces region. If an argument list contains a parameter name instead of a parameter value, then the value of this parameter is the value of the same parameter in the next higher level scope.

Thus in our example the parameter Luminance has the value 2 in the first trial and the value 90 in the second trial. The parameter StoreData has the value 0 in both trials of the first block and has the value 1 in all trials of the second block. The question mark as a parameter value signals the system to use the parameter's value from the next outer scope. Usually this will be the global value. The question mark is also used for those parameters which are dependent on what happens within a trial. The parameter ResponseTime is an example for this. The response time will be created during the trial and the parameter ResponseTime will get the value of the time measured. Thus the question mark indicates that we do not know the value of this parameter before the trial has been run. The same holds for TrialCounter which is a counter which is incremented at each trial. After a trial has been run all parameters have a value defined and these are used later for data file output.

Multiple Sessions

A single design file may define multiple sessions. Remember that a session is a sequence of blocks which itself is a sequence of trials. The sessions defined in a design file may actually contain different blocks and trials since it is possible to define different sessions, blocks, and trials in a single design file. Furthermore the procedure section of a design file may contain multiple copies of a session or may contain sequences of different sessions which may be assigned to different subject groups.

Here is a list of experimental scenarios with respect to the assignment of sessions to subjects.

Single subject, single session.
The most simple case of a single subject running a single session. This usually will be a demonstrations experiment.
Multiple subjects, single session.
The most simple serious case where a sample of subjects each runs a single session.
Multiple subjects, multiple sessions.
The case where each subject runs more than a single session and there are many subjects.

How Sessions are Selected

The sessions defined in the Procedure() node of a design file are implicitly numbered, starting with '1' for the first session defined. The experimental parameter SessionGroup is used to select a subset of the sessions defined for a given subject. Suppose we have 5 sessions defined in the Procedure() section of a design file. Setting

   SessionGroup = [1, 2, 3, 4, 5];

will run every session for every given subject at each single run of the design. Now suppose we only want to run sessions 1, 3, and 5. We then define

   SessionGroup = [1, 3, 5];

and every subject will only run this subset of sessions. We may also define something like

   SessionGroup = [1, 1, 3];

in order to run session 1 twice and then run session 3.

Session selection will usually be specific to groups of subjects. Every subject belongs to a subject group. If there are more than a single subject group then the parameter SubjectGroup can be used to assign a subject to a subject group. In this case the parameter SubjectGroup must be defined as a covariate factor. Suppose we have two subject groups. We define SubjectGroup as a covariate factor with two factor levels:

   CovariateFactor(SubjectGroup) {
      FactorLevel("treatment");
      FactorLevel("notreatment");
   }

Now suppose furthermore that the factor levels 'treatment' and 'notreatment' are associated with different sessions. We may then define the parameter SessionGroup as an 'operationalization parameter' of SubjectGroup:

   CovariateFactor(SubjectGroup, SessionGroup) {
      FactorLevel("treatment", [1, 2, 3]);
      FactorLevel("notreatment", [1, 4, 5]);
   }

This definition associates the sessions 1, 2, and 3 with the factor level 'treatment' and the sessions '1, 4, and 5 with the factor level 'notreatment'. Thus any subject who belongs to the subject group 'treatment' will only run the sessions 1, 2, and 3 while any subject belonging to subject group 'notreatment' will run the sessions 1, 4, and 5. Remember that any covariate factor will be asked for at the start of an experiment if it had not been defined on the command line. This means that after the experiment has been started the program will ask for the subject group level and will then select the proper sessions.

Subjects Running More than a Single Session

The previous examples assume that any subject runs the design file exactly once. This may be too restrictive. In many cases it will be necessary that a subject executes more than a single run. This may be controlled by the parameter SessionRuns. Suppose that every subject in the previous example will have to execute two runs with the first two sessions in the first and the final third session being executed in the second run. We define

   SessionRuns = [2, 1]; 

This tells PXLab to divide data collection into two runs. The first run executes the first 2 sessions defined by the current value of SessionGroup and the second run executes the final (3rd) session selected by SessionGroup.

Using the experimental parameter SessionRuns requires that PXLab has access to previous data files of any subject. This is achieved by starting the program with exactly the same subject code twice. PXLab will always try to find previous data files for the given subject. If such a data file is found then it will extract the necessary information from this data file and procede with data collection using all information in the previous data file. No covariate factor values will be asked for in this case since the subject code is sufficient to identify all data of the previous run.

In case of multiple runs for a single subject PXLab may be asked to join subsequent data files for a single subject. This is done by setting the experimental parameter JoinDataTrees to 1:

   JoinDataTrees = 1;

will result in a data tree file which contains the current and all previous data for a subject.

Note, however, that parameters from a previous data tree will only be extracted, if PXLab knows the SubjectCode value at startup. Thus the SubjectCode parameter value has to be given in the command line or must be contained in the design file for this to work properly. If SubjectCode is undefined at startup then the runtime session parameter dialog pops up and asks for the subject code and any other covariate factor levels. In this case covariate factor information cannot be read from previous data files.

Experiment() Node Arguments

The Experiment() node itself may have arguments. Suppose the Experiment() node is declared as

  Experiment(SubjectGroup) {
    ...
  }

Then the parameter SubjectGroup must be set at runtime. This may either be done from an external calling program or it may be done via a special pop-up dialog before the experiment is started. The mechanism is the same as the one which collects covariate factor levels.

Subject Grouping and Block Selection

In many cases of subject grouping it may be necessary to present different blocks of trials to different subject groups. This will frequently hold for experiments which have only a single session and use a between groups design. In this case it will be useful to create two or more subject groups and assign blocks of trials to subject groups.

A block of trials may be assigned to a subject group simply by defining the parameter ActiveSubjectGroups to be a block parameter and to enter the respective subject group in the parameter value:

  Context() {
    Block(BlockCounter, ActiveSubjectGroups) {
       ...
    }
    ...
  }

defines ActiveSubjectGroups as a block parameter. A block of trials is then assigned to a certain subject group if the current value of the parameter ActiveSubjectGroups contains the respective subject group name in its array of values:

      Block(?, "treatment") {
        Trial(...);
        ...
      }
      Block(?, ["treatment", "placebo"]) {
        Trial(...);
        ...
      }

The first of these two blocks is presented to the 'treatment'-group only while the second block is presented to both subject groups.

This mechanism only works for block and session arguments. Here is how the presentation procedure handles the active subject groups:

  1. It sets the block or session argument parameters to their respective values.
  2. It checks whether the current value of ActiveSubjectGroups contains the current value of SubjectGroup. If this is the case then the block start display and all trials in the block are run. If the current value of ActiveSubjectGroups does not contain the current value of SubjectGroups then the block start and end display and all trials of the respective block are skipped.

Note that this mechanism requires that the parameter ActiveSubjectGroups must explicitly be defined. If this is not done then all presentation blocks are executed and there is no restriction for the given subject group.

[This file was last updated on July 15, 2010, 12:07:01.]

[Home]    [Content]    [Previous Chapter]    [Next Chapter]