Virginia -
I see - it does shed light - and it makes sense - I hadn't imagined this
scenario before - and I guess SPM could warn you if this happens, though
at least it doesn't crash... ;-)
Rik
> Rik and James,
>
> It is funny that this should come up, a PhD student in our lab had a similar
> problem with columns of her design matrix with parametric modulation that
> some of the columns disappeared for some of the subjects. It turned out,
> after looking more carefully, that the randomization she had used for the
> experiment caused some of the sessions to contain only 2 or 3 of the 5
> possible values of the parametric modulation. We were originally trying to
> model the modulation up to a factor of three (cubic), but after we found
> this we left the modulation as linear and the problem with the missing
> columns was solved without having to change any of the default parameters of
> SPM5 regarding orthogonalisation. And I didn't have to look at where this
> was occurring in the code and I was more sure that the PhD student was using
> the right model.
>
> Hope this sheds some insight.
> Best,
> Virginia
>
>
> On Tue, 6 Jan 2009 14:14:49 +0000, Rik Henson <[log in to unmask]>
> wrote:
>
>
>> James -
>>
>> Firstly, just to clarify for others - SPM does not perform any
>> "auto-orthogonalisation" of regressors, except when using multiple
>> parametric modulations of the same condition.
>>
>> If you have multiple parametric modulations of the same condition and
>> these are (partially) correlated, this is not necessarily a problem.
>> Only if they are linearly-dependent is there a problem, which should
>> lead to blank regressors *with* orthogonalisation (not after turning it
>> off?), so I am a bit puzzled by your email (I am also confused why you
>> have different numbers of columns - I wasn't aware that SPM would ever
>> do this?). So is there something else going wrong with your batch
>> creation of design matrices?
>>
>> More generally, you do not necessarily need to be concerned about grey
>> bars indicating that betas for some columns are not estimiable unless
>> you are interested in contrasts like [0 1 0 0 ...] on just that column
>> (eg other contrasts, like [0 1 0 -1...] might well be estimiable). But I
>> assume you are interested in the former type of contrast (eg on a single
>> parametric modulator) and one way that you can bypass the contrast
>> manager's check is to define and estimate the contrast by a direct call
>> as below:
>>
>> SPM.xCon(n) = spm_FcUtil('Set',cname,'T','c',c,SPM.xX.xKXs);
>> spm_contrasts(SPM);
>>
>> where n is the next contrast number and c is the contrast (column
>> vector) you want to estimate (and 'T' can be 'F' instead). The
>> spm_FcUtil will actually reproject the contrast to make it estimiable,
>> but take care that the new project contrast is still interpretable.
>>
>> Rik
>>
>>
>>> Dear all,
>>>
>>> We're currently having problems with our design matrices/contrast
>>> analysis that I'd appreciate some help on. (FYI: SPM5, Matlab 7.6).
>>>
>>> Originally, our design matrices were occasionally showing differing
>>> numbers of columns as well as grey bars indicating that the betas were
>>> not uniquely specificied. Following Rik Henson's link yesterday I turned
>>> SPM's "auto-orthogonaliser" off and this resulted in matrices with the
>>> correct number of columns - but now showing the black lines that were
>>> previously (presumably) being excluded which explained the different
>>> sized matrices - many thanks for that.
>>>
>>> However, we still have the problem of columns that are
>>> non-uniquely-specified - which cannot be used in any contrasts (the
>>> contrast manager will not permit a "1" on any columns that had this
>>> (grey box)).
>>>
>>> Rather than explain the whole design, I wondered if anyone had any good
>>> advice on how generally to deal with betas not being uniquely specified
>>> - for example, is it best to drop the whole session? Can the contrast
>>> manager's refusal to run be over-ridden?
>>>
>>> I want to be able to batch process the contrasts and so ideally don't
>>> want to end up with different columns numbers with different parameters
>>> for each subject etc as this would mean I'd have to manually enter
>>> contrasts for each subject and with N=36 that'd take some time.
>>>
>>> If anyone has any thoughts on the best way forward that would be much
>>> appreciated.
>>>
>>>
>>> James Gilleen
>>> IOP
>>> London, SE5 8AF
>>> tel: 0207 848 0542
>>>
>>>
>> --
>>
>> -------------------------------------------------------
>> Dr Richard Henson
>> MRC Cognition & Brain Sciences Unit
>> 15 Chaucer Road
>> Cambridge
>> CB2 7EF, UK
>>
>> Office: +44 (0)1223 355 294 x522
>> Mob: +44 (0)794 1377 345
>> Fax: +44 (0)1223 359 062
>>
>> http://www.mrc-cbu.cam.ac.uk/people/rik.henson/personal
>> -------------------------------------------------------
>>
>
>
>
--
-------------------------------------------------------
DR RICHARD HENSON
MRC Cognition & Brain Sciences Unit
15 Chaucer Road
Cambridge, CB2 7EF
England
EMAIL: [log in to unmask]
URL: http://www.mrc-cbu.cam.ac.uk/people/rik.henson/personal
TEL +44 (0)1223 355 294 x522
FAX +44 (0)1223 359 062
MOB +44 (0)794 1377 345
-------------------------------------------------------
|