Hi Caspar,
On Nov 30, 2012, at 08:25 , Caspar M. Schwiedrzik wrote:
> Hi Doug and Sebastian,
> thanks for your input. I think I can confirm that it is the problem
> that Sebastian described. FS 5.1 uses betainc, which returns 0, even
> in Matlab R2011b.
> The workaround that Sebastian suggested works, with a slight modification.
> In line 888 in fast_selxavg3.m currently reads
> ind = find(pmat == 0); pmat(ind) = 1;
> That seems wrong to me, as -log10(1) gives 1.
> I replaced line 888 with
> ind = find(pmat == 0); pmat(ind) = eps(0);
> -log10(eps(0)) gives 323.3062.
> Sebastian's solution of pmat(ind) = eps underestimates the
> significance because eps is by default eps(1).
Oh, I did not make a precise proposal for change, just a quick thing to
test, and it seems quite okay to underestimate the P value, at least more
conservative than overestimating it :)
> Does that make sense?
>
> I confirmed that the time courses indicate a highly significant
> difference; I have 27 runs of block design; the problem happens both
> for contrasts against baseline and for contrasts between conditions; I
> currently have this problem only in one subject.
Well, then you have it, only in one subject significance was large
enough to cause this rounding artifact. Probamly the most conservative thing to
do would be to set the value of those voxels to the highest "real" P value
(unless you can deduce the real P value for thiose voxels) as otherwise FDR
might not work as expected any more. But I am not looking at the code so I am
basically just rambling here...
best
Sebastian
>
> Thanks, Caspar
>
>
>
>
> 2012/11/29 Sebastian Moeller <[email protected]>:
>> Hi Doug, hi Caspar,
>>
>> which matlab version are you using? We had some issues in the past that some
>> matlab 2007 and 2009 statistics toolbox versions returned p values of 0,
>> which obviously will not work as overlay, since those typically assume a
>> volume of:
>> -log10(p_value)
>> and on matlab 2007b (maci):
>>>> -log10(0.0)
>> ans =
>> Inf
>>>> -log10(eps)
>> ans =
>> 15.6536
>> So you should
>>
>> So test your input stat volumes for 0.0 and try to replace those with eps in
>> matlab and see how the overlay look then. Then try to teach fs-fast to do
>> this automagically :)
>> For saity checking have a look at the time course at those voxels (I assume
>> NHP block design data here), and remember if you can see the modulation in
>> the time courses with your bare eyes it will most likely be significant. So
>> at those voxels where the contrasts return zero I would expect really great
>> time courses with strong differences in modulation hiught between the
>> members of the -a and -c collections of contrast blocks.
>>
>> best
>> Sebastian
>>
>>
>> On Nov 29, 2012, at 09:55 , Douglas N Greve wrote:
>>
>>>
>>> Oh, I did not realize this was an fsfast issue, I thought you were using
>>> mri_glmfit. In that case, I'm not sure what could be causing the problem
>>> since the p-values are being computed by matlab. How many runs do you
>>> have? Is is a contrast that has a huge amount of power(eg, something vs
>>> fixation)? Does it happen in other subjects? One path to debugging is to
>>> run selxavg3-sess with -run-wise. This will create an analysis for each
>>> run separately. You can then see whether one run in particular is
>>> causing the problem.
>>> doug
>>>
>>> On 11/27/2012 08:34 PM, Caspar M. Schwiedrzik wrote:
>>>> Hi Doug,
>>>> I am afraid the p values are still too small in Free Surfer
>>>> Linux-centos4_x86_64-stable-pub-v5.1.0-full.
>>>> I redid
>>>> mkanalysis-sess
>>>> mkcontrast-sess
>>>> selxavg3-sess
>>>> in 5.1., it looks verz similar as in 4.5., including a whole of 0.0 in
>>>> the center of the cluster.
>>>> Any further advice?
>>>> Thanks,
>>>> Caspar
>>>>
>>>>
>>>>
>>>> 2012/11/26 Douglas Greve <[email protected]>:
>>>>> No, it does not. With version 5 I went to a simple AR1 model instead.
>>>>> doug
>>>>>
>>>>>
>>>>>
>>>>> On 11/26/12 10:34 PM, Caspar M. Schwiedrzik wrote:
>>>>>> Hi Doug,
>>>>>> thanks for the input. What I meant is that in version 5.1,
>>>>>> mkanalysis-sess does not seem to recognize the -taumax flag to set the
>>>>>> maximum delay for the autocorrelation function.
>>>>>> Caspar
>>>>>>
>>>>>>
>>>>>> 2012/11/26 Douglas N Greve <[email protected]>:
>>>>>>>
>>>>>>> On 11/26/2012 02:12 PM, Caspar M. Schwiedrzik wrote:
>>>>>>>> Hi Doug,
>>>>>>>> I'll do that.
>>>>>>>> Two quick follow-up questions regarding 5.1:
>>>>>>>> - it seems that I cannot specify taumax anymore in mkanalysis-sess. Is
>>>>>>>> there another argument that would allow me to set the autocorrelation?
>>>>>>> What do you mean by "set the autocorrelation"? You can turn it off with
>>>>>>> -no-whiten.
>>>>>>>
>>>>>>>> - in a block design, would refeventduration be the block length or the
>>>>>>>> length of the individual events within a block?
>>>>>>> The block length. This will not change the p-values, only percent signal
>>>>>>> change values (often not even looked at).
>>>>>>> doug
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Caspar
>>>>>>>>
>>>>>>>> 2012/11/26 Douglas N Greve<[email protected]>:
>>>>>>>>> Hi Caspar, I think I fixed this in later versions. If you upgrade, you
>>>>>>>>> can run the stats from 5.1 with recons from 4.5 (just don't mix recons
>>>>>>>>> from different versions).
>>>>>>>>> doug
>>>>>>>>>
>>>>>>>>> On 11/26/2012 01:15 PM, Caspar M. Schwiedrzik wrote:
>>>>>>>>>> Hi!
>>>>>>>>>> I ran into a funny problem when calculating contrasts in Freesurfer
>>>>>>>>>> 4.5.0.
>>>>>>>>>> Namely, the center of my cluster of significant voxels has a p-value
>>>>>>>>>> of -0.0, resulting in a funny whole where you would otherwise expect
>>>>>>>>>> to find the most significant voxel(s).
>>>>>>>>>> It seems that the p-value is too small. Is there a workaround
>>>>>>>>>> available?
>>>>>>>>>> Thank you very much,
>>>>>>>>>> Caspar
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Freesurfer mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Douglas N. Greve, Ph.D.
>>>>>>>>> MGH-NMR Center
>>>>>>>>> [email protected]
>>>>>>>>> Phone Number: 617-724-2358
>>>>>>>>> Fax: 617-726-7422
>>>>>>>>>
>>>>>>>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>>>>>>>>> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>>>>>>>>> Outgoing:
>>>>>>>>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Freesurfer mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The information in this e-mail is intended only for the person to whom
>>>>>>>>> it
>>>>>>>>> is
>>>>>>>>> addressed. If you believe this e-mail was sent to you in error and the
>>>>>>>>> e-mail
>>>>>>>>> contains patient information, please contact the Partners Compliance
>>>>>>>>> HelpLine at
>>>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to you
>>>>>>>>> in
>>>>>>>>> error
>>>>>>>>> but does not contain patient information, please contact the sender
>>>>>>>>> and
>>>>>>>>> properly
>>>>>>>>> dispose of the e-mail.
>>>>>>>>>
>>>>>>> --
>>>>>>> Douglas N. Greve, Ph.D.
>>>>>>> MGH-NMR Center
>>>>>>> [email protected]
>>>>>>> Phone Number: 617-724-2358
>>>>>>> Fax: 617-726-7422
>>>>>>>
>>>>>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>>>>>>> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>>>>>>> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>>>>>>>
>>>>
>>>
>>> --
>>> Douglas N. Greve, Ph.D.
>>> MGH-NMR Center
>>> [email protected]
>>> Phone Number: 617-724-2358
>>> Fax: 617-726-7422
>>>
>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>>> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>>> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>>>
>>> _______________________________________________
>>> Freesurfer mailing list
>>> [email protected]
>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>> --
>> Sebastian Moeller
>>
>> telephone: +1-626-325-8598 /+1-626-395-6523 / +1-626-395-6616
>> fax: 626-395-8826
>> German GSM: +49 - 15 77 - 1 90 31 41
>> mobile: +1-626-325-8598
>> +1-626-807-5242
>> US CDMA: +1-626-807-5242
>> [email protected]
>>
>> Division of Biology
>> MC 114-96
>> California Institute of Technology
>> 1200 East California Boulevard
>> CA 91125, Pasadena
>> USA
>>
>
> _______________________________________________
> Freesurfer mailing list
> [email protected]
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
--
Sebastian Moeller
telephone: +1-626-325-8598 /+1-626-395-6523 / +1-626-395-6616
fax: 626-395-8826
German GSM: +49 - 15 77 - 1 90 31 41
mobile: +1-626-325-8598
+1-626-807-5242
US CDMA: +1-626-807-5242
[email protected]
Division of Biology
MC 114-96
California Institute of Technology
1200 East California Boulevard
CA 91125, Pasadena
USA
_______________________________________________
Freesurfer mailing list
[email protected]
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
