Hi - no, it should be ok. The problem just comes at the stage of the
"contrast estimability" estimation - the results for those "problem"
contrasts are meaningless anyway - and the other contrasts _should_ be
fine. We'll put in a trap in feat_model to catch these dodgy values
in future though.
Cheers, Steve.
On 2 Jun 2009, at 22:22, James Porter wrote:
> Steve-
>
> Thanks for sending the TCL script to point me in the right
> direction. I was
> able to find the cause of the trouble pretty quickly with that help.
>
> What's going wrong is that the spots where there are empty EVs
> (missing
> conditions within some blocks) should be producing PPheights that
> are all
> 0.000000e+00, but in seemingly random fashion the PPheights will
> occasionally be huge values, like 9.094801e+14. This then throws off
> the
> calculations of the design.lcon files and, in turn, the featquery
> scaling
> factor.
>
> This runs in tandem with an earlier thread I sent:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0712&L=FSL&P=R18772
>
> My plan right now is to replace the off values with 0.000000e+00 in
> the
> design.con files and then re-run my gfeats to get the proper
> design.lcon
> values. However, I'd like to know if there are any possible issues
> stemming
> from these values at the lower level. For instance, would these
> PPheights
> skew the calculations that produce copes and z-maps for the other
> conditions, meaning that I should also re-run my lower-level stats
> before
> re-running my gfeats?
>
> Thanks,
> Jim
>
>
> On Tue, 2 Jun 2009 08:55:59 +0100, Steve Smith
> <[log in to unmask]> wrote:
>
>> Hi - here's the TCL code that calculates this scaling factor:
>>
>> set height_file design.mat
>> if { $thename == "cope" || $thename == "varcope" } {
>> set height_file design.con
>> }
>>
>> # get pe or cope number
>> set thenumber [ expr 1 + [ string trimleft [ file tail
>> $statsimage ]
>> "varcope" ] ]
>>
>> # get higher-level contrast height if it exists (this is the mean of
>> lower-level contrast heights)
>> set higherheight 1
>> if { [ file exists design.lcon ] } {
>> set higherheight [ exec sh -c "cat design.lcon" ]
>> }
>>
>> # get regressor scaling value from design.mat or design.con file
>> # set to 100 if scaling not set (ie FEAT directory was created by
>> old
>> version of FEAT)
>> set theheight [ exec sh -c "grep PPheights $height_file | awk
>> '{ print \$$thenumber }'" ]
>> if { $theheight != "" && $theheight != 0 } {
>> set theheight [ expr 100.0 * $theheight * $higherheight ]
>> } else {
>> set theheight 100
>> }
>>
>> # begin scaling command
>> set percentcommand "-mul $theheight"
>>
>> # divide by mean image unless is a higher-level analysis
>> if { [ imtest mean_func ] } {
>> set percentcommand "$percentcommand -div mean_func"
>> }
>>
>> so - the scaling should just be simply extracted from design.mat or
>> design.con files. If your lower-level design.con files seem correct,
>> then - is this being run on the output of higher-level analyses?
>> Seems
>> possible that this is the case, in which case $higherheight is also
>> estimated, using the value inside design.lcon - what values do you
>> have in there? If none of this helps elucidate matters, you can
>> upload the complete first-level and higher-level outputs relating to
>> this subject and we can have a look.
>>
>> Cheers.
>>
>>
>>
>> On 1 Jun 2009, at 22:49, James Porter wrote:
>>
>>> Hello Again-
>>>
>>> After some thorough searching, I have been unable to find anything
>>> to
>>> indicate that something special has happened with the design
>>> matrix of
>>> the problem subject. Below are three design.con files, first from
>>> the
>>> problem subject, then two others that don't generate featquery
>>> errors. I
>>> note no major differences. In the lower-level analyses (3 blocks per
>>> subject) there were some missing conditions that produce "nan"
>>> results for required effect estimates as shown in the covariance/
>>> required effect estimates, but this is not unique to the subject in
>>> question. Most subjects had missing conditions somewhere across the
>>> three blocks (yes, we learned our lesson on randomizing conditions!)
>>> but the "empty" copes were not passed up to the higher-level
>>> analyses.
>>>
>>> In checking through the raw fMRI volumes and the copeX.nii.gz images
>>> used in and output by the lower- and higher-level analysis, I find
>>> no
>>> outliers of super-huge values that could be skewing the percent
>>> signal
>>> change calculation. It seems to be within the featquery script that
>>> something funny is happening. Any other suggestions of where to look
>>> to
>>> track down this problem?
>>>
>>> Thanks!
>>> Jim
>>>
>>>
>>> ************
>>> /ContrastName1 T+S
>>> /ContrastName2 T-S
>>> /ContrastName3 S-T
>>> /NumWaves 4
>>> /NumContrasts 3
>>> /PPheights 5.555556e-01 5.555556e-01 5.555556e-01
>>> /RequiredEffect 9.689 9.689 9.689
>>>
>>> /Matrix
>>> 1.000000e+00 -1.000000e+00 1.000000e+00 -1.000000e+00
>>> 1.000000e+00 -1.000000e+00 -1.000000e+00 1.000000e+00
>>> -1.000000e+00 1.000000e+00 1.000000e+00 -1.000000e+00
>>>
>>> ************
>>> /ContrastName1 T+S
>>> /ContrastName2 T-S
>>> /ContrastName3 S-T
>>> /NumWaves 4
>>> /NumContrasts 3
>>> /PPheights 5.555556e-01 5.555556e-01 5.555556e-01
>>> /RequiredEffect 9.689 9.689 9.689
>>>
>>> /Matrix
>>> 1.000000e+00 -1.000000e+00 1.000000e+00 -1.000000e+00
>>> 1.000000e+00 -1.000000e+00 -1.000000e+00 1.000000e+00
>>> -1.000000e+00 1.000000e+00 1.000000e+00 -1.000000e+00
>>>
>>> ************
>>> /ContrastName1 T+S
>>> /ContrastName2 T-S
>>> /ContrastName3 S-T
>>> /NumWaves 4
>>> /NumContrasts 3
>>> /PPheights 5.000000e-01 5.000000e-01 5.000000e-01
>>> /RequiredEffect 6.670 6.670 6.670
>>>
>>> /Matrix
>>> 1.000000e+00 -1.000000e+00 1.000000e+00 -1.000000e+00
>>> 1.000000e+00 -1.000000e+00 -1.000000e+00 1.000000e+00
>>> -1.000000e+00 1.000000e+00 1.000000e+00 -1.000000e+00
>>>
>>>
>>> ---------
>>> Jim Porter
>>> Graduate Student
>>> Clinical Science & Psychopathology Research
>>> University of Minnesota
>>>
>>> Steve Smith wrote:
>>>> <div class="moz-text-flowed" style="font-family: -moz-fixed">Hi -
>>>> this is calculated from the design.con header which tells you the
>>>> peak-peak height of the "effective regressor" (see our NeuroImage
>>>> efficiency paper) associated with contrast 1 - so have a look at
>>>> this file and the design in general - did something go weirdly
>>>> wrong with this design matrix?
>>>> Cheers.
>>>> On 12 May 2009, at 18:18, James Porter wrote:
>>>>> Howdy-
>>>>>
>>>>> I have a follow-up question. I'm going through the featquery shell
>>>>> script
>>>>> and logs, and I'm not quite able to follow all parts.
>>>>> Specifically, I can't
>>>>> tell where the value 24.2645433553 comes from in the following log
>>>>> line.
>>>>>
>>>>> /opt/bliss/fsl/bin/fslmaths stats/cope1 -mul 24.2645433553 -div
>>>>> mean_func
>>>>> cope1.feat/featquery/tmp
>>>>>
>>>>> For the problem subject discussed below, the value is
>>>>> 4.91862312076e+16, and
>>>>> this seems to be the source of the goofy percent signal change
>>>>> values.
>>>>> However, I'm still unable to diagnose the root problem without
>>>>> knowing where
>>>>> the value in question comes from. Can you point me in the right
>>>>> direction?
>>>>>
>>>>> Thanks in advance,
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 7 May 2009 15:08:22 -0500, James Porter <[log in to unmask]>
>>>>> wrote:
>>>>>
>>>>>> Hello-
>>>>>>
>>>>>> Can anybody clue me in on an obvious reason why one subject (47
>>>>>> other
>>>>>> subjects do not show this problem) would have insanely large
>>>>>> percent
>>>>>> signal change values--but not z-values--when running a masked
>>>>>> featquery
>>>>>> examination? We're talking absurdly large values, like
>>>>>> 370,200,000,000,000 % signal change, and the values are identical
>>>>>> for
>>>>>> all of the descriptive stats (i.e., min, mean, max are all the
>>>>>> same value).
>>>>>>
>>>>>> --
>>>>>> ---------
>>>>>> Jim Porter
>>>>>> Graduate Student
>>>>>> Clinical Science & Psychopathology Research
>>>>>> University of Minnesota
>>>>>
>>>> ---------------------------------------------------------------------------
>>>> Stephen M. Smith, Professor of Biomedical Engineering
>>>> Associate Director, Oxford University FMRIB Centre
>>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>>>> +44 (0) 1865 222726 (fax 222717)
>>>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>>>> ---------------------------------------------------------------------------<
>>>> /div>
>>>
>>>
>>> --
>>> ---------
>>> Jim Porter
>>> Graduate Student
>>> Clinical Science & Psychopathology Research
>>> University of Minnesota
>>>
>>
>>
>> ---------------------------------------------------------------------------
>> Stephen M. Smith, Professor of Biomedical Engineering
>> Associate Director, Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>> +44 (0) 1865 222726 (fax 222717)
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>> ---------------------------------------------------------------------------
>
---------------------------------------------------------------------------
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
---------------------------------------------------------------------------
|
