Back to the main page.
Bug 2372 - ft_timelockstatistics crashes on data with keeptrials='yes' and cfg.parameter='avg'
| Status | CLOSED FIXED |
| Reported | 2013-11-12 20:35:00 +0100 |
| Modified | 2015-01-12 09:23:27 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Matt Mollison - 2013-11-12 20:35:09 +0100
Matlab 2012b, OS X 10.9, fieldtrip-20131111 The issue is with timelock data that contains all the trials (so data.trial exists and dimord='rpt_chan_time'), and also has the avg field. When I run ft_timelockstatistics with cfg.parameter='avg', the function (correctly) removes the trial field on line 84. However, I believe it should also either modify or completely remove the dimord field because the avg field has the dimord 'chan_time'. Because dimord='rpt_chan_time' still exists, private/prepare_timefreq_data crashes on line 352 because the dimord dimensions do not get set correctly in its subfunction forcedimord (the check on line 475 finds that it still has a dimord field and does not properly set it to be 'chan_time'; this final point is the source of the crash and could be resolved by removing the dimord field earlier in ft_timelockstatistics). Don't know how I haven't run into this before, but I guess I never really set keeptrials='yes' in ft_timelockanalysis.
Matt Mollison - 2013-11-12 20:40:38 +0100
After testing, completely removing dimord in ft_timelockstatistics does not seem to be an option, but somehow it needs to be changed to reflect the contents of the avg field (fixdimord?).
Jan-Mathijs Schoffelen - 2013-11-14 09:44:34 +0100
Hi Matt, Thanks for posting this. The handling of data structures with numeric data that have different 'dimord's is known to be a bit buggy at the moment. We have the intention to streamline this in the future, but this is not likely to happen anytime soon. In a nutshell, our intention would be to have more than one dimord once a data structure contains numeric fields that have different specifications along their matrix 'axes'. So, for your example this would lead to a timelock structure with both a 'avgdimord' of 'chan_time', and a 'trialdimord' of 'rpt_chan_time'. (for that matter, once there's a covariance as well, it should also have a 'covariancedimord' of 'rpt_chan_chan' (or 'chan_chan') However, this involves a non-trivial change to a lot of code, which potentially breaks the whole toolbox, so we are a bit anxious to get really started. Would it be OK for you that for the time being you work around it? Indeed, as you already noticed the following should work: Prior to calling ft_timelockstatistics, do: tlck = rmfield(tlck, 'trial'); tlck.dimord = 'chan_time';
Matt Mollison - 2013-11-14 19:23:32 +0100
(In reply to comment #2) Sure, I'm happy to work around it for now in the way that you suggested, though it does seem reasonable to me to do the overwriting of dimord='chan_time' in ft_timelockstatistics, because what else could the dimord possibly be if cfg.parameter='avg'? (To answer my own question, I guess it could be 'chan_chan'). Anyway, I'm looking forward to the multiple dimord feature, good luck with all the changes.
Jan-Mathijs Schoffelen - 2014-07-22 14:27:01 +0200
*** Bug 2659 has been marked as a duplicate of this bug. ***
Jan-Mathijs Schoffelen - 2014-07-22 14:27:22 +0200
*** Bug 2660 has been marked as a duplicate of this bug. ***
Diego Lozano Soldevilla - 2014-07-25 17:20:53 +0200
(In reply to Jan-Mathijs Schoffelen from comment #5)