Example scripts for implementing batch mode analysis for a block design with a few events thrown in

• The design was a block design.
• Subjects participated in two runs each.
• Each run had a fixed structure of alternation among the conditions, but the order of runs was counterbalanced across subjects.

The scripts:

Top-level scripts:

• get_ts1_sinfo.m: contains subject information, including exam numbers, mappings of series numbers onto image types, i.e. coplanar, epi, etc.
• ts1_start.m: top-level script. This is the script that is invoked from the matlab command line. It does the following things:
1. Calls a routine (convert_format) which converts GE format data into Analyze format (using slightly modified versions of Souheil's GE2SPM code) and puts things into the correct directories (based on mappings in get_ts1_sinfo). Note that my naming convention is slightly different from the one that most other folks tend to use, and 'convert_format' may need to be modified slightly to accomodate this difference.
2. Submits the batch script (ts1_batch) to the spm batch interface.
• ts1_batch.m: top-level batch script. In this script, the user selects which processing/analysis modules to run and which subjects to run it on. This script then constructs the analysis queue structure that SPM operates on.

Scripts controlling individual components of the batch jobs:

• ts1_defaults.m: sets various spm defaults
• ts1_realign.m: creates structures containing parameters for realignment, coregistration, and normalization.  The different realignment, coregistration, and normalization toggles in ts1_batch.m  (e.g. COREG_COPLANAR_2_HIRES) refer to different indices in the arrays of realign, coreg, and normalize structures.
• ts1_smooth.m: sets up structure that handles smoothing of images.  There are actually two structures.  The first handles smoothing of non-normalized resliced images, and the second handles normalized images.
• ts1_model_protos.m: Sets up a default prototypical model structure for the experiment.  This is where all of the conditions, condition onsets, condition types, i.e. epoch or event, convolutions, etc. are defined. Unlike the other batch modules which usually have only a single structure associated with them, the model part of the batch interface requires several structures.
• Absolutely mandatory are:
1. model
2. conditions
3. bf_ep -- for epoch (block) based design
4. bf_ev -- for events in design
• Optional structures are
1. parametrics
2. regressors
3. stochastics
For this particular experiment, the prototype corresponds to the model that would be used for a subject whose run order was 1, 2.  For subjects receiving the blocks in reverse order, the conditions structure array indices in the model structure would have to be switched.  This is done dynamically by ts1_model_norm.m, based on information in get_ts1_sinfo.m. Also, the script contains specifications for two different types of models with different numbers of conditions. The particular model to be used is selected through the 'use_model_proto' global variable.
• ts1_model_norm.m: Generates subject specific models based on a desired prototype specified in ts1_model_protos.m.  Maps the appropriate files, etc. Also adds regressors (linear trend and/or motion parameter estimates) if desired.
• ts1_contrasts.m: This is where the contrast structure is generated.  This is done in two steps.  First, all of the desired contrasts are specified using my own scheme which is then translated into the actual contrast structure.  My scheme was developed to use the names of conditions to dynamically generate the vectors of +1 -1 0, etc, rather than specifying the numbers directly.  This makes things much easier if you decide to change models by adding or deleting a condition, because the same contrast will be generated even if the column of a particular condition has changed. In its present implementation, this scheme will not acccommodate contrasts such as -2 -1 +1 +2, etc.

Miscellaneous (non-spm-batch) scripts:

• ts1_clean.m: Removes intermediate and rawdata files
• ts1_display.m: Invokes Matthew Brett's display_slices routine to create various plots.

General utility scripts (not specific to this experiment)

• convert_format.m: Converts GE data to Analyze format using information in the get_*_sinfo.m file.

Things to watch out for ...

Some global variables are currently being used to handle situations for which global variables are not the optimal way to do it.  This is most obvious when using the mutual information global flag.  If the flag is set true, mutual info is used for all coregistration, even though this might not be the desired action.  One way to get around this might be to have coreg structures for mutual info coregistrations defined in separate mfiles.

Debug your lower-level scripts by running them alone, i.e. invoke ts1_realign and make sure it runs cleanly.  Nothing bad will happen if you do this and it will save you time in the long run.  Debugging from within spm batch mode is a pain in the ass.

Naming conventions for paths:  The scripts assume a specific naming of the directory tree.

In order to get the batch mode to work all the way, I had to modify the following scripts from the SPM distribution.  They must appear on the Matlab path ahead of the SPM distribution.

• spm_bch_bchmat.m
• spm_coreg_ui.m
• spm_get_ons.m
• spm_input.m

Disclaimer