<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<span style="font-size: 11pt;">Dear Andreas and Makoto,</span>
<p> </p>
<p><span style="font-size: 11pt;">of course, I am working on it! I am a bit reluctant to update the eeglab version in the middle of my analysis – wouldn’t this potentially result in additional inconsistencies? I used eeglab 13.4.4b on my main computer; I just
ran additional tests with the other version.</span></p>
<p> </p>
<p><span style="font-size: 11pt;">I eventually managed to figure out what affects data precision: irrespective of the eeglab version (I tested with 13.4.4b, 13.5.4b, and 13.6.5b), changes result from saving/loading a dataset, depending on the settings in "memory
and other options". You cannot see this when debugging your own script as it occurs in the process of saving/ loading itself. I think the function responsible is
<em style="">pop_loadset()</em> which has a different effect on the data format (EEG.data) depending on how the dataset was saved before (<em style="">option_savetwofiles</em> in
<em style="">pop_editoptions</em> , GUI: Memory and other options: "If set, save not one but two files for each dataset").</span></p>
<p> </p>
<p><span style="font-size: 11pt;"><em style="">option_savetwofiles</em> = 1 --> two files are saved: .set and .fdt</span></p>
<p><span style="font-size: 11pt;"><em style="">option_savetwofiles</em> = 0 --> one file is saved: .set</span></p>
<p> </p>
<p><span style="font-size: 11pt;">When now loading the dataset again with <em style="">
pop_loadset</em>, the format remains single if only the set-file exists; the data is converted to double if the data is stored in the fdt-file (2 files were saved before). I think it happens within the function
<em style="">eeg_checkset</em> which is called by <em style="">pop_loadset.</em></span><em style="font-size: 11pt;">
</em><span style="font-size: 11pt;">I don’t know if this is intentional or not… but if so, it’s very difficult to track (at least for me).</span></p>
<p> </p>
<p><span style="font-size: 11pt;">To get back to my data: what I can tell is that the data format is single precision after the import (I import Brain Vision Analyzer files with the eeglab extension: bva-io v1.5.12,
<em>pop_loadbv</em>). As far as I understand the function, this seems to be "standard" (unless an older Matlab version is used).<br>
</span></p>
<p><br>
<span style="font-size: 11pt;"></span><span style="font-size: 11pt;"></span></p>
<p><span style="font-size: 11pt;">I am currently working on a simplified version I can more easily pass on to you (raw data files, code). Of course I rejected the identical bad segments (same mat-file with start/end points used for rejection).</span></p>
<p><span style="font-size: 11pt;">Thanks for the comment on linked mastoid reference - I am still not sure here but I hope it becomes clear in the script then.</span></p>
<p><br>
<span style="font-size: 11pt;"></span></p>
<p><span style="font-size: 11pt;">Best,</span></p>
<p><span style="font-size: 11pt;">Hannah</span></p>
<p><br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>Von:</b> Makoto Miyakoshi <mmiyakoshi@ucsd.edu><br>
<b>Gesendet:</b> Donnerstag, 02. Februar 2017 04:09<br>
<b>An:</b> Hiebel, Hannah (hannah.hiebel@uni-graz.at)<br>
<b>Cc:</b> Andreas Widmann; eeglablist@sccn.ucsd.edu<br>
<b>Betreff:</b> Re: [Eeglablist] ICA running very slowly</font>
<div> </div>
</div>
<div>
<div dir="ltr">Dear Hannah,
<div><br>
</div>
> or take on your offer, Makoto.
<div><br>
</div>
<div>Actually I'm not a debugging guy. The official bug report place for EEGLAB is Bugzilla.</div>
<div><a href="https://sccn.ucsd.edu/bugzilla/enter_bug.cgi">https://sccn.ucsd.edu/bugzilla/enter_bug.cgi</a><br>
</div>
<div>You can file your claim here. Thank you for your patience and cooperation.</div>
<div><br>
</div>
<div>That being said, if you don't see any error message, it's very hard for me to imagine what is wrong. You may also want to give us more info. For example, it is always very slow... if not, when it becomes slow etc. Also, all other basic info, such as sampling
rate, data length, number of channels, etc etc...</div>
<div><br>
</div>
<div>Makoto</div>
<div><br>
</div>
<div><br>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Jan 30, 2017 at 2:51 AM, Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at">hannah.hiebel@uni-graz.at</a>)
<span dir="ltr"><<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-color:rgb(204,204,204); border-left-style:solid; padding-left:1ex">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:calibri,arial,helvetica,sans-serif; background-color:rgb(255,255,255)">
<span style="font-size:11pt; font-family:calibri,sans-serif">Dear Andreas and Makoto,</span>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">thank you for your additional suggestions.</span></p>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">I am not really familiar with bugtracker, the easiest way for me would be sharing the data via Dropbox and send you the link separately, or take on your offer, Makoto.</span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">I wonder if I could have a look at the code first – if you spot anything wrong here, you wouldn’t have to make the effort with the actual data. I could then easily provide the datasets sufficient
to run runica().<br>
</span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">Andreas, if I wanted to provide everything you’d need to replicate my whole routine, I’d have to make available several datasets, additional mat-files (e.g. with info about bad segments) and functions...
</span></p>
<p><span style="font-size:11pt">I'd suggest starting with the final datasets and then decide how to best proceed, if that's okay.</span>
<br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">Regarding your comments:</span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">I thought only re-referencing to average reference reduces the data rank (I re-referenced to linked mastoids instead). Maybe there are other steps potentially resulting in rank-deficiency I am
not aware of?</span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">When checking with
<em><span style="font-family:calibri,sans-serif">rank(EEG.data(:,:)</span></em><em>)</em> it seems fine, I don’t know if that’s sufficient.</span></p>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<span style="font-size:11pt">Makoto,</span><span style="font-size:11pt; font-family:calibri,sans-serif"> I am working with ICA for the first time and thus have no experience with how clean the data should be. One subject with long runtimes indeed doesn’t have
the best data quality (neck muscle tension) but I had the same runtime problems in a subject with very clean EEG data.<br>
</span>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">Thank you, Andreas, for your explanation regarding single vs. double precision. On additional remark: When I run the same script on different computers with different Matlab/eeglab version (same
setting for <em>option_single</em>), the format (EEG.data) differs (single /double precision) – this is quite confusing for me, to be honest.
</span></p>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<p><span style="font-size:11pt; font-family:calibri,sans-serif">Best regards,<br>
Hannah</span></p>
<p><br>
<span style="font-size:11pt; font-family:calibri,sans-serif"></span></p>
<div style="color:rgb(33,33,33)">
<hr style="display:inline-block; width:98%">
<div id="gmail-m_-8281970758256134213divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>Von:</b> Makoto Miyakoshi <<a href="mailto:mmiyakoshi@ucsd.edu" target="_blank">mmiyakoshi@ucsd.edu</a>><br>
<b>Gesendet:</b> Donnerstag, 26. Jänner 2017 23:20<br>
<b>An:</b> Andreas Widmann<br>
<b>Cc:</b> Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>);
<a href="mailto:eeglablist@sccn.ucsd.edu" target="_blank">eeglablist@sccn.ucsd.edu</a>
<div>
<div class="gmail-h5"><br>
<b>Betreff:</b> Re: [Eeglablist] ICA running very slowly</div>
</div>
</font>
<div> </div>
</div>
<div>
<div class="gmail-h5">
<div>
<div dir="ltr">Dear Hannah and Andreas,
<div><br>
</div>
<div>> Btw, did you check data rank?<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Yeah this is another thing. runica() has a rank checker, but if it does not work well for whatever reason, the calculation will be difficult!</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">By the way, AMICA does not seem to change its computation speed regardless of data quality. runica() does it clearly.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Hannah, if you are willing to share the data, just give me data that is sufficient to run runica(). If you don't have any method to share data, I'll give you SCCN server account separately. Let me know.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Makoto</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 25, 2017 at 10:04 AM, Andreas Widmann <span dir="ltr">
<<a href="mailto:widmann@uni-leipzig.de" target="_blank">widmann@uni-leipzig.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-color:rgb(204,204,204); border-left-style:solid; padding-left:1ex">
Dear Hannah,<br>
<br>
please provide one affected raw dataset and the absolutely minimal script demonstrating the issue (mainly your various filters, artifact rejection, and possibly epoching or re-referencing etc). Presumably easiest is via the bugtracker. Also better for future
reference.<br>
<br>
Using double precision is indeed to be preferred (the firfilt plugin uses double precision for filtering internally anyway). Note however, that data are not automatically converted to double precision using the option (but NOT converted automatically to single).
Depending on your raw data format and importer you possibly have to do that manually. Btw, did you check data rank?<br>
<br>
Best,<br>
Andreas<br>
<span class="gmail-m_-8281970758256134213gmail-im gmail-m_-8281970758256134213gmail-HOEnZb"><br>
> Am 25.01.2017 um 15:18 schrieb Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>) <<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>>:<br>
><br>
> Dear Andreas, dear Makoto,<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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?<br>
><br>
> 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…).<br>
><br>
> Thanks a lot for your effort,<br>
> Hannah<br>
><br>
><br>
> Hannah Hiebel, Mag.rer.nat.<br>
> Cognitive Psychology & Neuroscience<br>
> Department of Psychology, University of Graz<br>
> Universitätsplatz 2, 8010 Graz, Austria<br>
</span><span class="gmail-m_-8281970758256134213gmail-im gmail-m_-8281970758256134213gmail-HOEnZb">> Von: Andreas Widmann <<a href="mailto:widmann@uni-leipzig.de" target="_blank">widmann@uni-leipzig.de</a>><br>
> Gesendet: Donnerstag, 19. Jänner 2017 21:53<br>
> An: Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>)<br>
> Cc: <a href="mailto:eeglablist@sccn.ucsd.edu" target="_blank">eeglablist@sccn.ucsd.edu</a><br>
> Betreff: Re: [Eeglablist] ICA running very slowly<br>
><br>
> Hi Hannah,<br>
><br>
> 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?<br>
><br>
> Best,<br>
> Andreas<br>
><br>
>> Am 19.01.2017 um 09:41 schrieb Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>) <<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>>:<br>
>><br>
>> Dear Alberto and Tarik,<br>
>><br>
>> 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.<br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> This gives me the impression that the higher cut-off frequency causes the problems (or maybe stopband edge and attenuation are more decisive?).<br>
>> 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.<br>
>><br>
>> I’d be very grateful if anyone could provide more insight!<br>
>><br>
>> Best,<br>
>> Hannah<br>
>><br>
>><br>
>> Hannah Hiebel, Mag.rer.nat.<br>
>> Cognitive Psychology & Neuroscience<br>
>> Department of Psychology, University of Graz<br>
>> Universitätsplatz 2, 8010 Graz, Austria<br>
>><br>
</span>
<div class="gmail-m_-8281970758256134213gmail-HOEnZb">
<div class="gmail-m_-8281970758256134213gmail-h5">>> Von: Alberto Sainz <<a href="mailto:albertosainzc@gmail.com" target="_blank">albertosainzc@gmail.com</a>><br>
>> Gesendet: Mittwoch, 18. Jänner 2017 04:29<br>
>> An: Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>)<br>
>> Cc: <a href="mailto:eeglablist@sccn.ucsd.edu" target="_blank">eeglablist@sccn.ucsd.edu</a><br>
>> Betreff: Re: [Eeglablist] ICA running very slowly<br>
>><br>
>> 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.<br>
>><br>
>> I know your data is larger but just to say that the processor (and probably the RAM if is too small) matters a lot.<br>
>><br>
>> Good luck<br>
>><br>
>> 2017-01-16 20:26 GMT+01:00 Hiebel, Hannah (<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">hannah.hiebel@uni-graz.at</a>)<<a href="mailto:hannah.hiebel@uni-graz.at" target="_blank">ha<wbr>nnah.hiebel@uni-graz.at</a>>:<br>
>> Dear all,<br>
>><br>
>> 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).<br>
>><br>
>> 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.<br>
>> 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?<br>
>><br>
>> 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.<br>
>><br>
>> Any advice would be very much appreciated!<br>
>><br>
>> Many thanks in advance,<br>
>> Hannah<br>
>><br>
>><br>
>> Hannah Hiebel, Mag.rer.nat.<br>
>> Cognitive Psychology & Neuroscience<br>
>> Department of Psychology, University of Graz<br>
>> Universitätsplatz 2, 8010 Graz, Austria<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Eeglablist page: <a href="http://sccn.ucsd.edu/eeglab/eeglabmail.html" rel="noreferrer" target="_blank">
http://sccn.ucsd.edu/eeglab/ee<wbr>glabmail.html</a><br>
>> To unsubscribe, send an empty email to <a href="mailto:eeglablist-unsubscribe@sccn.ucsd.edu" target="_blank">
eeglablist-unsubscribe@sccn.uc<wbr>sd.edu</a><br>
>> For digest mode, send an email with the subject "set digest mime" to <a href="mailto:eeglablist-request@sccn.ucsd.edu" target="_blank">
eeglablist-request@sccn.ucsd.e<wbr>du</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Eeglablist page: <a href="http://sccn.ucsd.edu/eeglab/eeglabmail.html" rel="noreferrer" target="_blank">
http://sccn.ucsd.edu/eeglab/ee<wbr>glabmail.html</a><br>
>> To unsubscribe, send an empty email to <a href="mailto:eeglablist-unsubscribe@sccn.ucsd.edu" target="_blank">
eeglablist-unsubscribe@sccn.uc<wbr>sd.edu</a><br>
>> For digest mode, send an email with the subject "set digest mime" to <a href="mailto:eeglablist-request@sccn.ucsd.edu" target="_blank">
eeglablist-request@sccn.ucsd.e<wbr>du</a><br>
><br>
><br>
<br>
______________________________<wbr>_________________<br>
Eeglablist page: <a href="http://sccn.ucsd.edu/eeglab/eeglabmail.html" rel="noreferrer" target="_blank">
http://sccn.ucsd.edu/eeglab/ee<wbr>glabmail.html</a><br>
To unsubscribe, send an empty email to <a href="mailto:eeglablist-unsubscribe@sccn.ucsd.edu" target="_blank">
eeglablist-unsubscribe@sccn.uc<wbr>sd.edu</a><br>
For digest mode, send an email with the subject "set digest mime" to <a href="mailto:eeglablist-request@sccn.ucsd.edu" target="_blank">
eeglablist-request@sccn.ucsd.e<wbr>du</a></div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail-m_-8281970758256134213gmail_signature">
<div dir="ltr">Makoto Miyakoshi<br>
Swartz Center for Computational Neuroscience<br>
Institute for Neural Computation, University of California San Diego<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">Makoto Miyakoshi<br>
Swartz Center for Computational Neuroscience<br>
Institute for Neural Computation, University of California San Diego<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>