Back to the main page.
Bug 3062 - ft_spike_maketrials
| Status | CLOSED FIXED |
| Reported | 2016-02-03 13:36:00 +0100 |
| Modified | 2016-05-05 20:30:40 +0200 |
| Product: | FieldTrip |
| Component: | spike |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Suzanne Martens - 2016-02-03 13:36:32 +0100
I'm having a problem with the ft_spike_maketrials function. I've encoutered this problem while going through the tutorials "spike" and "spikefield". Using the code (unaltered aside from the comments) from the spikefield tutorial, the following shows when the error is encountered: %% Reading in spike data addpath('C:\Users\10167188\Desktop\Suzanne Martens\Fieldtrip\fieldtrip-20160128') addpath('C:\Users\10167188\Desktop\Suzanne Martens\Fieldtrip\data') ft_defaults filename = 'p029_sort_final_01.nex'; spike = ft_read_spike(filename); %% Selecting two channels cfg = []; cfg.spikechannel = {'sig002a_wf', 'sig003a_wf'}; spike = ft_spike_select(cfg, spike); %% Creating a trial structure cfg = []; cfg.dataset = filename; cfg.trialfun = 'trialfun_stimon_samples'; cfg = ft_definetrial(cfg); %% Reading in LFP data using trial structure for preprocessing cfg.channel = {'AD01', 'AD02', 'AD03', 'AD04'}; cfg.padding = 10; cfg.dftfreq = [60-1*(1/10):(1/10):60+1*(1/10) ]; cfg.dftfilter = 'yes'; data_lfp = ft_preprocessing(cfg); %% Creating trial structure for spike data cfg = []; cfg.dataset = filename; cfg.trialfun = 'trialfun_stimon_samples'; cfg = ft_definetrial(cfg); trl = cfg.trl; %% Adding trial structure to spike data cfg = []; cfg.hdr = data_lfp.hdr; cfg.trlunit = 'samples'; cfg.trl = trl; %% ERROR spikeTrials = ft_spike_maketrials(cfg,spike) % the input is spike data with 2 channels % Error using ft_checkconfig (line 208) % The field cfg.progress is not allowed % Error in ft_spike_maketrials (line 127) % cfg = ft_checkconfig(cfg, 'allowed', {'datafile', 'dataformat', 'dataset', %'event','headerfile', 'headerformat', 'trialfun', 'trlunit', %'timestampspersecond', 'hdr', 'trl'}); Mysteriously, rebooting Matlab sometimes helps but not always. The problem does not seem to be related to how the path is defined. I've checked ft_checkconfig but I can't quite figure out what's wrong (or what I'm doing wrong), aside from what the error already tells us. Just deleting cfg.progress from the cfg structure does not solve the problem either. I hope I'm not just overlooking some basic step, if that's the case I apologize for filing this bug report. Thanks in advance for your help! Best, Suzanne Martens
Suzanne Martens - 2016-02-12 15:44:34 +0100
So I got back to this problem today. First, I just downloaded the newest version of fieldtrip. The error also occured using this version. I found out that adding 'progress' at line 191 of function ft_checkconfig "fixes" the problem. It seems like I just manually changed what fields are allowed to be in the cfg structure in spike. Allowing the cfg structure to have a .progress field seems to change the output though. The spikeTrials structure I get is different from the one described in the toturial (mine contains 15 extra data points for one channel and 13 extra data points for the other). So it seems like I've "fixed" the error but broken the ft_spike_maketrials function in the process. I checked the cfg structure in spike before running spikeTrials = ft_spike_maketrials(cfg,spike) and it contained a .progress field. However removing the field does not produce errors when 'progress' is added to the ft_checkconfig structure, and as already mentioned before it does not solve the problem when the ft_checkconfig function is unaltered. Apparently, this .progress field is not the one causing the problem. Is a .progress field added somewhere in the workspace of the ft_spike_maketrials function? Maybe in a cfg structure that this function produces in it's own workspace? I am very confused, am I the only one who encountered this problem even though this is code from the tutorials, not my own code? This might be unrelated but another user reported encountering errors in spike related functions when using the code from the tutorial. I am talking about this bugreport: ID = 3058, title: error using cross-correlations ft_spike_xcorr, http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3058 . This user is also seemingly alone in this problem, but I have encountered this error too. Could the two possibly be related? I forgot to include last time that I work with matlab version 2013b on Windows 7. I'd appreciate any help, thank you for your time! Best, Suzanne Martens
Jan-Mathijs Schoffelen - 2016-02-19 13:47:54 +0100
Hi Suzanne, Thanks for the preliminary detective work. Your suggested change to ft_checkconfig is indeed the solution to the problem. Some very brief background: -ft_checkconfig can be called to very critically evaluate the input cfg. -this is however hardly ever done, apart from in many of the ft_spike functions. -the option progress indeed is (in a somewhat obscure/hidden way) added to the cfg, and is needed to keep track of some stuff (which typically the user is not interested in, nor should she be worried about it). -in order for ft_checkconfig not to choke on this obscure field it should be explicitly told not to worry about it. In short, I will incorporate your suggestion in the code. With respect to the other issues you mention: - I don't know whether bug 3058 is related, or something else - the extra number of data points is probably not due to your fix, but may be related to another known issue (which as far as I know has not been addressed yet -> bug 2045). If you are happy with this change, can you change the status of this bug to resolved? We should follow up on the other issues elsewhere.
Suzanne Martens - 2016-02-19 13:58:26 +0100
Ok, thank you very much! I'll just change it manually then for now. Good to know I don't need to worry about the few extra data points too much.
Jan-Mathijs Schoffelen - 2016-02-19 14:04:48 +0100
You're welcome, although I am not sure whether or not to worry about those data points. Is this what bug 2045 suggests?