Hello,

This is a note I'm filing about an issue I ran into with art_batch, and a fix to art.m that I think may address it.

The problem is that when reading the info from an SPM.mat file, art.m stumbles in the case where a modulator has been applied to a term. The reason is that the code wants to get a simple list of column numbers and names corresponding to the non-nuisance variables, and expects there to be one name entry per col -- but SPM, in its wisdom, uses a nested list in the case of a modulator, which breaks that assumption. For example, instead of

SPM.Sess(1).U(1) =
name: {'cue'}
ons: [32x1 double]
dur: [32x1 double]
(etc.)

corresponding to a single condition with no modulator, with a pmod term added it might store

SPM.Sess(1).U(1) =

name: {'cue' 'cuexcuevalue^1'}
ons: [32x1 double]
dur: [32x1 double]
(etc.)

and those entries now correspond to two columns instead of one.

Here is my proposed fix, which seems to work for me, though I have only tested it on one example (with parametric modulator, single session): flatten the name list over all U entries, then use that to get appropriate col values.


OLD:

cols = [cols SPM.Sess(s).col(1:length(SPM.Sess(s).U))]; %#ok % extracts only effects of interest (no covariates) from design matrix
names=cat(1,names,SPM.Sess(s).U(:).name);


NEW:

tempnames = {SPM.Sess(s).U.name};
tempnames = [tempnames{:}];
names = [names tempnames];
cols = [cols SPM.Sess(s).col(1:length(tempnames))];



For the main operations of ART this is only cosmetic since it just involves getting column labels, but it does make art_batch crash without some kind of fix.


Jamie