[MINC-development] -O3 breaks N3

[Vladimir S. FONOV]

Hello,


finally, I was able to achieve the same results, by recompiling EBTKS
as a static library (before I had it built as a shared library).

So, now both versions produce exactly the same output.

On Thu, Apr 19, 2012 at 10:59 AM, Vladimir S. FONOV
<vladimir.fonov at gmail.com> wrote:
> Hello,
>
>
> I managed to track problem further. First, it turns out that on new
> build  volume_stats -nocache produced very different results then
> default (and consistent with old build). So, I disabled caching.
>
> On top of that, I discovered that the output of sharpen_hist changed
> significantly.
>
> If i give the following command line:
>
> sharpen_hist -blur -fwhm .2 -noise 0.01 -range 762.440430 1646.982788
> hist.txt hist.sharp.txt
>
> the output is very different for two  versions (and none of them makes
> any sense whatsoever).
>
> See attached file hist.txt, hist_old.sharp.txt and hist_new.shart.txt
>
> the graph showing the histogram is here:
> http://www.bic.mni.mcgill.ca/~vfonov/temp/histograms.png
>
>
>
>
> On Wed, Apr 18, 2012 at 11:58 PM, Claude LEPAGE
> <claude at bic.mni.mcgill.ca> wrote:
>> Hi,
>>
>> I think the damping of 1.0e-7 might be a little bit too
>> aggressive and not enough damping can cause the matrix
>> system to be ill-conditioned. While it works in most cases,
>> a value of 1.0e-6 will give similar results and will be
>> more robust numerically. Can you try that?
>>
>> Claude
>>
>>> Hello Everybody,
>>>
>>> Turns out that N3 is broken with -O2. Actually , compiling
>>> http://packages.bic.mni.mcgill.ca/tgz/N3-1.12.0.tar.gz
>>> using standard ./configure & make
>>>
>>> produces a code which seem to work, but essentially corrects nothing at
>>> least when applied to icmb 00100 t1w scan :
>>> (
>>> /data/ipl/user01/rotor/icbm_recovery/shell-pipe-analy-circa2006/native/mni_icbm_00100.001.t1.mnc.gz
>>> on the bic system)
>>>
>>> it produces an imp file :
>>>
>>> MNI Field File
>>> %Wed Apr 18 18:40:53 2012>>> /opt/minc2/bin/nu_estimate_np_and_em
>>> -parzen -log -sharpen 0.1 0.01 -iterations 100 -stop 0.0001 -shrink 4
>>> -auto_mask -nonotify -b_spline 1.0e-7 -distance 200 -quiet -execute
>>> -clobber -nokeeptmp -tmpdir /tmp/nu_correct_7795/
>>> mni_icbm_00100.001.t1.mnc auto_mni_icbm_00100.001.t1.nuc.imp
>>> Version = 0.9.0;
>>> Field_Type = B_Spline;
>>> Distance = 200;
>>> Domain =
>>>       -81.519097598907     89.3619937534825
>>>       -95.84404     164.15596
>>>       -155.813426545559     107.579156148442;
>>> Coefficients =
>>>      6.93367797718816e-310
>>>      6.93367797718816e-310
>>>                          0
>>>                          0
>>>                          0
>>> ...(all zeroes)
>>>                          0;
>>>
>>> When compiled on ubuntu 11.04 , gcc version 4.5.2
>>>
>>> Interestingly, the same tool compiled on Debian 5, gcc version 4.3.4
>>> works as expected.
>>>
>>>
>>>
>>>
>>> On 12-04-15 07:41 AM, Andrew Janke wrote:
>>> > Absolutely...
>>> >
>>> > Claude, remember also the bug we fixed in EBTKS's spline
>>> > implementation a long time back that was causing crashed on some files
>>> > with certain magic dimensions. I can't think of how this might break
>>> > anything (we added an episilon IIRC) but it was a change we had to
>>> > make.
>>> >
>>> > I for one am keen to keep N3 as it is and I don't see it being a
>>> > problem to force -02 behaviour during the compile. I have used N4 but
>>> > often revert to N3, probably because it's a beast I know.
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Vladimir S. FONOV ~ vladimir <dot> fonov <at> gmail <dot> com
>>> _______________________________________________
>>> MINC-development mailing list
>>> MINC-development at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>>>
>> _______________________________________________
>> MINC-development mailing list
>> MINC-development at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
>
>
> --
> Best regards,
>
>  Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com



-- 
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com