Back to the main page.

Bug 3075 - Can't use cfg.inputfile and cfg.outputfile commands

Reported 2016-02-19 15:08:00 +0100
Modified 2016-05-05 20:29:19 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P5 normal
Assigned to: Jan-Mathijs Schoffelen
Depends on:
See also:

rinbl64 - 2016-02-19 15:08:57 +0100

OVERVIEW: CFG.INPUT: Using cfg.inputfile in functions (this example ft_preprocessing) produces error message: Error using ft_preamble_loadvar (line 46) cfg.inputfile should not be used in conjunction with giving input data to this function Error in ft_preamble (line 56) evalin('caller', ['ft_preamble_' cmd]); Error in ft_preprocessing (line 178) ft_preamble loadvar data CODE TO REPRODUCE: cfg = []; cfg.inputfile = 'trialfile.mat'; [outdata] = ft_preprocessing(cfg); CFG.OUTPUT: Using cfg.outputfile in functions (this example ft_preprocessing) produces error message: Output argument "data" (and maybe others) not assigned during call to "ft_preprocessing" CODE TO REPRODUCE: cfg = []; cfg.dataset = filename1; cfg.headerfile = filename1; cfg.trialfun = 'ft_trialfun_general'; cfg.trialdef.eventtype = 'STI101'; cfg.trialdef.eventvalue = [211]; cfg.trialdef.prestim = 1; % in seconds cfg.trialdef.poststim = 1; % in seconds cfg.outputfile = 'trialfile.mat' cfg = ft_definetrial(cfg); [outputdata] = ft_preprocessing(cfg); %% note we know that this code does not produce this error if we write: ft_preprocessing(cfg) without "[outputdata] =" however because we are having errors with cfg.input this error is included in this report. BUILD DATE & HARDWARE: fieldtrip 20160216 Windows 7 Enterprise EXAMPLE DATA:

Jan-Mathijs Schoffelen - 2016-02-22 09:15:21 +0100

I cannot reproduce the issue with the below code. There is no reason to assume that there's something wrong with fieldtrip. I tested it on linux and windows using matlab2014b. Please try out the below code. Feel free to reopen if the problem persists. data = []; data.trial = {randn(2,1000)}; data.time = {(0:999)./1000}; data.label = {'chan01';'chan02'}; filename1 = [tempname,'.mat']; filename2 = [tempname,'.mat']; save(filename1, 'data'); % check cfg = []; cfg.inputfile = filename1; %cfg.lpfilter = 'yes'; %cfg.lpfreq = 10; datanew = ft_preprocessing(cfg); cfg.outputfile = filename2; ft_preprocessing(cfg); datanew2 = ft_preprocessing(cfg); tmp = load(filename2); assert(isequal(rmfield(datanew2,'cfg'), rmfield(,'cfg'))); %the callinfo may be different

Robert Oostenveld - 2016-02-22 10:42:10 +0100

I tested with matlab 2015b on osx and the test script from the pull request does not work for me. I also get >> test_bug3075 Error using ft_preamble_loadvar (line 46) cfg.inputfile should not be used in conjunction with giving input data to this function where on line 45 margin returns 2 (although I would expect it to be 1). I suspect that nargin is sensing the number of inputs to ft_preamble rather than the number of inputs to ft_preprocessing. Using "evalin" in various ways, I am NOT able to get the correct number of input arguments from ft_preprocessing. If I add to ft_preprocessing at the start ft_nargin = nargin; and replace if (nargin>1) by if (ft_nargin>1) then it works. Note that there is also a warning in the editor that "Use of Nargin in a script will be removed in the future". I suggest to replace revision by ft_revision (*) and to add ft_nargin to all functions that also have revision. *) although that should be revised as well

Robert Oostenveld - 2016-02-22 10:44:02 +0100

(In reply to Robert Oostenveld from comment #2) I will do this. ... and while I am at it, I will also rename "abort" to "ft_abort" for consistency between all variables that are passed between the main function and pre/post-ambles.

Robert Oostenveld - 2016-02-22 10:47:37 +0100

(In reply to Robert Oostenveld from comment #3) the same issue as with nargin is also present in nargout (use in ft_postamble_savevar). I will also use ft_nargout for that reason.

Jan-Mathijs Schoffelen - 2016-02-22 10:51:08 +0100

OK, which once more illustrates the necessity of reporting the MATLAB version...

rinbl64 - 2016-02-22 10:53:01 +0100

(In reply to Jan-Mathijs Schoffelen from comment #5) My apologies, I missed noting the version in this report.

Jan-Mathijs Schoffelen - 2016-02-22 10:56:42 +0100

No worries, but don't let it happen again :o).

Robert Oostenveld - 2016-02-22 11:19:57 +0100

I resolved it in prior to merging, I tested with 2015b and with 2012b (both on os x).