Back to the main page.

Bug 2513 - check data field consistency through different data type structures

Reported 2014-03-26 10:55:00 +0100
Modified 2014-03-26 16:41:19 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Linux
Importance: P5 normal
Assigned to: Diego Lozano Soldevilla
Depends on:
See also:

Diego Lozano Soldevilla - 2014-03-26 10:55:01 +0100

Some fieldtrip functions have strong expectations on specific data type fields and each field should represent data in a specific way (i.e. rpt_chan_time). However, in some cases there're different field names for the same datatype with exactly the same data respresentation. The problem arises when in cases of same data representation but different field name, getting error because the strong expectations that the calling fucntion has on specific field name, not regarding data representation (dimord) Example: We've different ft_append* functions for different datatypes: ./ft_appendsource.m ./ft_appendtimelock.m ./ft_appenddata.m ./ft_appendspike.m ft_appendtimelock can append timelock structures that contain 'trial' or 'avg' fieldnames but not other fields (no cfg.parameter option): timelock = []; timelock.dimord = 'chan_time'; timelock.label = {'cz'}; timelock.avg = rand(1,600); timelock.time = (1:600)./600; timelock.var = rand(1,600); - append avg field: ft_appendtimelock([],timelock,timelock) ans = time: [1x600 double] label: {'cz'} trial: [2x1x600 double] dimord: 'rpt_chan_time' cfg: [1x1 struct] - append trial field: timelock.trial = rand(1,600); ft_appendtimelock([],timelock,timelock) ans = time: [1x600 double] label: {'cz'} trial: [2x1x600 double] avg: [1x600 double] var: [1x600 double] dimord: 'rpt_chan_time' cfg: [1x1 struct] - append xxx field: timelock = []; timelock.dimord = 'chan_time'; timelock.label = {'cz'}; = rand(1,600); timelock.time = (1:600)./600; timelock.var = rand(1,600); ft_appendtimelock([],timelock,timelock) ans = time: [1x600 double] label: {'cz'} dimord: 'rpt_chan_time' cfg: [1x1 struct] Neither "var" and xxx field were appended. Also, when you input "avg" field you get "trial" as output (see related bugs). After a long discussion with Robert, he made a test script (see attachment) to check about different fields that each datatype can contain through the historical preprocessed data. Here is the output of the test script: collection = timelock: {'avg' 'cfg' 'cov' 'dimord' 'dof' 'dofvec' 'elec' 'fsample' 'grad' 'label' 'numcovsamples' 'numsamples' 'time' 'trial' 'var'} freq: {'cfg' 'crsspctrm' 'cumsumcnt' 'cumtapcnt' 'dimord' 'elec' 'foi' 'fourierspctrm' 'freq' 'grad' 'label' 'labelcmb' 'powspctrm' 'time' 'toi'} raw: {'cfg' 'elec' 'fsample' 'grad' 'hdr' 'label' 'offset' 'sampleinfo' 'time' 'trial' 'trialdef'} comp: {'cfg' 'fsample' 'grad' 'label' 'sampleinfo' 'time' 'topo' 'topolabel' 'trial' 'unmixing'} grad: {'balance' 'chanori' 'chanpos' 'chantype' 'chanunit' 'coilori' 'coilpos' 'coordsys' 'label' 'labelorg' 'tra' 'type' 'unit'} elec: {'chanpos' 'elecpos' 'label' 'unit'} source: {'avg' 'cfg' 'cumtapcnt' 'df' 'dim' 'freq' 'frequency' 'inside' 'method' 'outside' 'pos' 'time' 'trial' 'vol'} volume: {} unknown: {} There're all possible datatype fields that fieldtrip could provide (might be some fields are depreciated in recent versions). Now the challenge consist to check all ft_datatype_* functions to see if they're consistent with the preprocessed data.

Johanna - 2014-03-26 11:03:24 +0100

I recall I still have some open bugs on ft_appendtimelock. Sorry they are low priority for me now, so if someone else is eager to fix them, feel free to reassign. see bug 1013, bug 1014, and bug 2186

- 2014-03-26 13:56:31 +0100

In order to keep it manageable, start with ft_functions that take timelock-structures, and check in those functions whether these have hard-coded assumptions related to expected data fields. Take it from here.

- 2014-03-26 13:57:26 +0100

Also, add the output of the previous query to the respective ft_datatype_XXX functions.

Diego Lozano Soldevilla - 2014-03-26 16:41:19 +0100

(In reply to n.lam from comment #3) Test script and doc updated Adding test_bug2513.m Transmitting file data . Committed revision 9314. Sending ft_datatype_comp.m Sending ft_datatype_freq.m Sending ft_datatype_raw.m Sending ft_datatype_sens.m Sending ft_datatype_source.m Sending ft_datatype_timelock.m Transmitting file data ...... Committed revision 9315.