[Eeglablist] ICA running very slowly
Hiebel, Hannah (hannah.hiebel@uni-graz.at)
hannah.hiebel at uni-graz.at
Wed Jan 25 06:18:04 PST 2017
Dear Andreas, dear Makoto,
I have re-run the pre-processing routine and ICA for one of the affected subjects with consistent Matlab version (R2015b) and still get the same results in terms of runtime (>40 h / 14.5 h / < 1h depending on the previously used high-pass filter). Thus, the problems don’t seem to have been caused by inconsistent versions.
Thank you Makoto for your suggestion, I haven’t used the trimOutlier() plugin so far - I will try to check for outliers that way. If bad data quality was the reason, shouldn’t the long runtimes (in a specific subject) occur irrespective of the used high-pass filter?
One aspect I noticed is that the data format (EEG.data) is single precision – could this be the problem? I’ve just read in the PREP pipeline paper that double precision computation is essential for filtering; it is mentioned that the eeg_checkset function converts EEG data to single precision per default and one should override this default by changing the eeglab settings (pop_editoptions, set option_single to false). I have changed the eeglab options following the instructions on the eeglab wiki page ('File' -> 'Memory and other options' -> 'If set, use single precision under...' uncheck it). In my understanding this should be the same, right?
I appreciate your offer to try replicate the problem. I am not sure though what I would have to make available to you - would the pre-processed dataset(s) of one affected subject be sufficient? Also, do you need to be able to actually run my scripts or would it be enough to see the relevant parts of the code? (because in the main scripts I also retrieve information from additional files and call custom-made functions to process co-registered eye-tracking data…).
Thanks a lot for your effort,
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<mailto:hannah.hiebel at uni-graz.at>) <hannah.hiebel at uni-graz.at<mailto: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<mailto:albertosainzc at gmail.com>>
Gesendet: Mittwoch, 18. Jänner 2017 04:29
An: Hiebel, Hannah (hannah.hiebel at uni-graz.at<mailto:hannah.hiebel at uni-graz.at>)
Cc: eeglablist at sccn.ucsd.edu<mailto: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<mailto:hannah.hiebel at uni-graz.at>)<hannah.hiebel at uni-graz.at<mailto: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<mailto: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<mailto: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<mailto: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<mailto:eeglablist-request at sccn.ucsd.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20170125/dc18bdda/attachment.html>
More information about the eeglablist
mailing list