Back to the main page.
Bug 1519 - ft_componentanalysis error when no IC are found
| Status | CLOSED FIXED |
| Reported | 2012-06-12 12:22:00 +0200 |
| Modified | 2019-08-10 11:56:11 +0200 |
| Product: | FieldTrip |
| Component: | preproc |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | All |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Francesco Di Pompeo - 2012-06-12 12:22:05 +0200
An error is generated in ft_componentanalysis when no Indipendent Component are found using fastICA. The error is due to a matrix product with empty matrix. It is independent by the launch script or kind of data. May be an ~isempty requirement before the calculation (if it is the only with this problem) is enough. This is the command window: Whitening... Check: covariance differs from identity by [ 1.54801e-013 ]. Used approach [ defl ]. Used nonlinearity [ tanh ]. Using initial guess. Starting ICA calculation... IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. IC 1 ........................................................................................................................................................................................................ Component number 1 did not converge in 200 iterations. Too many failures to converge (6). Giving up. ??? Error using ==> mtimes Inner matrix dimensions must agree. Error in ==> ft_componentanalysis at 605 comp.trial{trial} = scale * unmixing * data.trial{trial}; Error in ==> hcp_doICARMEG at 145 comp = ft_componentanalysis(cfg, data_meg);
Robert Oostenveld - 2012-06-12 16:19:30 +0200
Hi Francesco The error is indeed ugly. What is your suggested way of dealing with this? We could return a structure that is empty (which I'd find confusing and which will cause other errors later in the script) or in ft_componentanalysis return a more informative error like error('the decomposition did not converse, no components could be extracted');
Francesco Di Pompeo - 2012-06-13 01:48:37 +0200
Robert, I think this is a very rare case when managing MEG data, but it can happens more often using many iterations. It is the first case for me in MEG/EEG analysis, but in other cases can happens often. According to my experience, the possible solutions are two: 1) re-starting the current iteration with a different random state (perhaps the next one). 2) Storing an empty structure. Please consider that in others analysis I perform (not MEG or EEG) ICA is not converging often. In this case although FastICA returns an empty matrix I don't have big problems using my codes. I think the first approach is more safe but I don't know if it's possible to implement it in fieldtrip. Stopping the ICA analysis may be fastidious especially when, like in my case, you are analyzing many subjects or recordings and all the pipeline stops. There are other solutions but according to me are less correct and elegant. Let me know what you think...
Robert Oostenveld - 2012-06-13 09:02:10 +0200
(In reply to comment #2) Re 1) I think this is something for the user to do, so the ft_componentanalysis function should not do it. The user knows better whether and how often he wants to restart, or whether some changes to the params or data are desired. Re 2) an empty structure would in the next analysis step not be recognized as valid fieldtrip data structure. So the consequence is that in the analysis pipeline the problem is shifted to a later step (e.g. sourceanalysis with method=mne will fail) which will confuse the user more than having an error at the location where the actual problem is. I suggest the user does try comp = ft_componentanalysis(cfg, data) catch % the user interaction (re 1) goes here end and have changed the ft_componentanalysis function to give a meaningful error. manzana> svn commit ft_componentanalysis.m Sending ft_componentanalysis.m Transmitting file data . Committed revision 6046.
Francesco Di Pompeo - 2012-06-18 16:10:53 +0200
Hi Robert, sorry but I don't agree... This is a bug of ft_component analysis since an empty result of fastica is not an error, but only a particular result! It can be due to the data but also, and in my experience more likely, to the choice of the starting random initialization. Consider that in the case in which many iteration are performed it is a real problem since you don't know why and when the problem can happen stopping your analysis may be running for a day. I don't know what you want to do, but in the case of HCP code we need a modified version, perhaps a special one. Thanks, Francesco
Robert Oostenveld - 2012-07-02 10:27:18 +0200
upon request I'll implement a workaround
Robert Oostenveld - 2012-07-02 10:40:28 +0200
(In reply to comment #4) I have implemented megconnectome/analysis_functions/hcp_componentanalysis.m which does what you have requested. The normal fieldtrip behavior remains the same, i.e. the ft function does not return an empty "comp" structure, but rather an informative error that fastica did not return any components. The hcp_componentanalysis wrapper restarts the decomposition as many times as you want. @Francesco: Please make your own further improvements to that function in github.