Back to the main page.
Bug 2513 - check data field consistency through different data type structures
| Status | ASSIGNED |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1656http://bugzilla.fcdonders.nl/show_bug.cgi?id=1616http://bugzilla.fcdonders.nl/show_bug.cgi?id=1452http://bugzilla.fcdonders.nl/show_bug.cgi?id=2186 |
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'}; timelock.xxx = 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.