Back to the main page.

Bug 2054 - use rollback_provenance consistently when calling a high-level FT function from another

Status NEW
Reported 2013-03-13 17:45:00 +0100
Modified 2014-07-17 09:18:16 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to:
Depends on:
See also:

Robert Oostenveld - 2013-03-13 17:45:29 +0100

when fixing bug 2051 (ft_math) I had to solve a problem with updating the data representation. This required % ensure that the data in all inputs has the same channels, time-axis, etc. tmpcfg = []; tmpcfg.parameter = cfg.parameter; [varargin{:}] = ft_selectdata(tmpcfg, varargin{:}); whereafter I could have done cfg.parameter = tmpcfg.parameter; to copy it back into the main cfg. However, discussing this with Eelke we figured out that both the cfg and the data are affected by this, and therefore need to be updated. This is also the case in for example ft_volumesegment, where if cfg.downsample ~= 1 tmpcfg = []; tmpcfg.downsample = cfg.downsample; tmpcfg.smooth = 'no'; % smoothing is done in ft_volumesegment itself mri = ft_volumedownsample(tmpcfg, mri); end The consequence of this is that in the provenance the user will see an extra ft_volumedownsample box that he did not explicitly ask for. The user calls ft_volumesegment, that ft_volumedownsample is called should remain hidden. Idem for ft_math: The user calls ft_math, that ft_selectdata is called should remain hidden. Instead of the first solution in ft_math, I now did tmpcfg = []; tmpcfg.parameter = cfg.parameter; [varargin{:}] = ft_selectdata(tmpcfg, varargin{:}); % restore the provenance information [cfg, varargin{:}] = rollback_provenance(cfg, varargin{:}); where rollback_provenance takes care of the provenance AND of merging the tmpcfg back into the original cfg. This new approach (which is much cleaner w.r.t. provenance) needs to be implemented consistently.

Robert Oostenveld - 2013-03-13 17:46:47 +0100

the following functions seem to be implied here mac001> grep -l tmpcfg *.m ft_appendfreq.m ft_artifact_ecg.m ft_artifact_eog.m ft_artifact_jump.m ft_artifact_muscle.m ft_componentanalysis.m ft_connectivityanalysis.m ft_connectivityplot.m ft_databrowser.m ft_denoise_pca.m ft_dipolefitting.m ft_headmovement.m ft_math.m ft_megrealign.m ft_multiplotER.m ft_multiplotTFR.m ft_mvaranalysis.m ft_prepare_headmodel.m ft_prepare_layout.m ft_prepare_leadfield.m ft_prepare_mesh.m ft_prepare_sourcemodel.m ft_redefinetrial.m ft_rejectartifact.m ft_singleplotER.m ft_singleplotTFR.m ft_sourceanalysis.m ft_sourceinterpolate.m ft_sourceplot.m ft_sourcestatistics.m ft_statistics_montecarlo.m ft_stratify.m ft_volumenormalise.m ft_volumerealign.m ft_volumereslice.m ft_volumesegment.m ft_volumewrite.m

Robert Oostenveld - 2014-07-03 17:42:04 +0200

(In reply to Robert Oostenveld from comment #1) These are the functions that call ft_selectdata but not rollback_provenance: mac011> grep -L rollback_provenance `grep -l ft_selectdata.*cfg *.m` ft_channelnormalise.m ft_channelrepair.m ft_componentanalysis.m ft_connectivityanalysis.m ft_connectivityplot.m ft_denoise_pca.m ft_denoise_synthetic.m ft_freqdescriptives.m ft_megplanar.m ft_megrealign.m ft_multiplotER.m ft_preprocessing.m ft_redefinetrial.m ft_rejectvisual.m ft_removetemplateartifact.m ft_resampledata.m ft_scalpcurrentdensity.m ft_singleplotER.m ft_sourcestatistics.m The updates of these functions are at risk of introducing the error that is reported in bug #2625.