[Eeglablist] ICA running very slowly

Hiebel, Hannah (hannah.hiebel@uni-graz.at) hannah.hiebel at uni-graz.at
Fri Jan 20 07:50:20 PST 2017


Dear Andreas,

okay, I see. I thought  that using different versions might potentially have resulted in inconsistencies in pre-processing.
The long ICA runtimes were not restricted to a  particular Matlab version though (R2014a vs. R2015b) - I tried on different computers for the affected subjects and observed long runtimes on both.
Did you notice longer runtimes with R2014a compared to R2016a?

However, just to be sure I will re-run the pre-processing and ICA with one Matlab version and give you an update as soon as possible.

Best,
Hannah

Hannah Hiebel, Mag.rer.nat.
Cognitive Psychology & Neuroscience
Department of Psychology, University of Graz
Universitätsplatz 2, 8010 Graz, Austria

Tel.: +43 (0)316 380-5080
email: hannah.hiebel at uni-graz.at

________________________________________
Von: Andreas Widmann <widmann at uni-leipzig.de>
Gesendet: Freitag, 20. Jänner 2017 13:53
An: Hiebel, Hannah (hannah.hiebel at uni-graz.at)
Cc: eeglablist at sccn.ucsd.edu
Betreff: Re: [Eeglablist] ICA running very slowly

Dear Hannah,

> Indeed, I sometimes used a different Matlab version (2015b vs. 2014a) and already wondered if this might be somehow related. Do think that could be the source of the problem?
Yes, this could indeed be related. I noticed a massive difference in ICA runtime between R2014a and R2016a. I never checked in detail which of the intermediate versions introduced the change.  I assume this is due to some optimizations of JIT compiler, math libs, and/or parallelization.

> I believe I re-ran the scripts for the affected subjects on one computer (Matlab 2015b) but I can’t tell for sure. Would you suggest re-running it again and check if it changes anything before making the data available?
Yes, that would be good.

Best,
Andreas

> Best,
> Hannah
>
> Hannah Hiebel, Mag.rer.nat.
> Cognitive Psychology & Neuroscience
> Department of Psychology, University of Graz
> Universitätsplatz 2, 8010 Graz, Austria
>
> Von: Andreas Widmann <widmann at uni-leipzig.de>
> Gesendet: Donnerstag, 19. Jänner 2017 21:53
> An: Hiebel, Hannah (hannah.hiebel at uni-graz.at)
> Cc: eeglablist at sccn.ucsd.edu
> Betreff: Re: [Eeglablist] ICA running very slowly
>
> Hi Hannah,
>
> I would like to try to replicate this behavior. Could you please make available one of the affected datasets and the relevant parts of the code used for pre-processing and ICA, e.g. via the bugtracker or Dropbox? Are there possibly data discontinuities without boundary markers? Did you keep MATLAB version constant?
>
> Best,
> Andreas
>
>> Am 19.01.2017 um 09:41 schrieb Hiebel, Hannah (hannah.hiebel at uni-graz.at) <hannah.hiebel at uni-graz.at>:
>>
>> Dear Alberto and Tarik,
>>
>> thank you very much for your suggestions. I work on a computer with i7 3.60 GHz processor, 8 GB RAM or notebook with i7 2.5 GHz and 8GB Ram – this should be okay.
>> Gladly, the ICA eventually finds a solution and the IC maps look good. However, the question for me is still why does the ICA become >10 times slower after changing the pre-processing routine. I’ve continued testing and indeed the high-pass filter seems to be responsible for the differences.
>>
>> In my recent routine I used the eeglab windowed sinc FIR filter with 1 Hz cut-off frequency, 1 Hz transition bandwidth, 0.001 passband ripple, Kaiser window. When I change the filter (settings) while keeping all other steps the same, I see huge differences in ICA runtime in some subjects. That is, when using a 0.1 Hz Butterworth filter instead, ICA is running fast again (< 1h for the subjects where it took > 30h before). With the eeglab basic FIR filter with 1 Hz passband edge and default settings defined by the internal heuristic (resulting in 0.5 Hz cut-off, 1 Hz trans. bandwidth) it’s also running much faster in most subjects but already takes >20h in the “problematic” cases.
>>
>> This gives me the impression that the higher cut-off frequency causes the problems (or maybe stopband edge and attenuation are more decisive?).
>> That's very surprising as I would not have expected the filter to have such an impact and a higher cut-off is normally recommended.
>>
>> I’d be very grateful if anyone could provide more insight!
>>
>> Best,
>> Hannah
>>
>>
>> Hannah Hiebel, Mag.rer.nat.
>> Cognitive Psychology & Neuroscience
>> Department of Psychology, University of Graz
>> Universitätsplatz 2, 8010 Graz, Austria
>>
>> Von: Alberto Sainz <albertosainzc at gmail.com>
>> Gesendet: Mittwoch, 18. Jänner 2017 04:29
>> An: Hiebel, Hannah (hannah.hiebel at uni-graz.at)
>> Cc: eeglablist at sccn.ucsd.edu
>> Betreff: Re: [Eeglablist] ICA running very slowly
>>
>> I would suggest to try in a different computer. I have been applying ICA in a 14 electrode 30min continuous EEG recording (around 40mb) in two different computers. 2Ghz dual core computer took 1h. 2.2Ghz i7 takes around 5 minutes.
>>
>> I know your data is larger but just to say that the processor (and probably the RAM if is too small) matters a lot.
>>
>> Good luck
>>
>> 2017-01-16 20:26 GMT+01:00 Hiebel, Hannah (hannah.hiebel at uni-graz.at)<hannah.hiebel at uni-graz.at>:
>> Dear all,
>>
>> I am using ICA to clean my EEG data for eye-movement related artifacts. I’ve already done some testing in the past to see how certain pre-processing steps affect the quality of my decomposition (e.g. filter settings). In most cases, it took approximately 1-2 hours to run ICA for single subjects (62 channels: 59 EEG, 3 EOG channels).
>>
>> Now that I run ICA on my final datasets it suddenly takes hours over hours to do only a few steps. It still works fine in some subjects but in others runica takes up to 50 hours. I observed that in some cases the weights blow up (learning rate is lowered many times); in others it starts right away without lowering the learning rate but every step takes ages.
>> I’ve done some troubleshooting to see if a specific pre-processing step causes this behavior but I cannot find a consistent pattern. It seems to me though that (at least in some cases) the high-pass filter played a role – can anyone explain how this is related? Could a high-pass filter potentially be too strict?
>>
>> On the eeglablist I could only find discussions about rank deficiency (mostly due to using average reference) as a potential reason. I re-referenced to linked mastoids – does this also affect the rank? When I check with rank(EEG.data(:, :)) it returns 62 though, which is equal to the number of  channels. For some of the “bad” subjects I nonehteless tried without re-referencing – no improvement. Also, reducing dimensionality with pca ("pca, 61") didn’t help.
>>
>> Any advice would be very much appreciated!
>>
>> Many thanks in advance,
>> Hannah
>>
>>
>> Hannah Hiebel, Mag.rer.nat.
>> Cognitive Psychology & Neuroscience
>> Department of Psychology, University of Graz
>> Universitätsplatz 2, 8010 Graz, Austria
>>
>> _______________________________________________
>> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
>> To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.ucsd.edu
>> For digest mode, send an email with the subject "set digest mime" to eeglablist-request at sccn.ucsd.edu
>>
>> _______________________________________________
>> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
>> To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.ucsd.edu
>> For digest mode, send an email with the subject "set digest mime" to eeglablist-request at sccn.ucsd.edu
>
>




More information about the eeglablist mailing list