Back to the main page.

Bug 2221 - problem plotting two averages at once with ft_multiplotER

Status CLOSED WONTFIX
Reported 2013-07-18 13:43:00 +0200
Modified 2014-06-18 12:33:36 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Linux
Importance: P3 normal
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also: http://bugzilla.fcdonders.nl/show_bug.cgi?id=2160

Sara Bögels - 2013-07-18 13:43:38 +0200

Created attachment 496 Averages for 2 conditions of subject 10. It is not possible to plot these together with cfg.xlim = [-2.5 4]; For 2 of my 24 participants, the function ft_multiplotER gives an error-message when I try to plot two conditions at the same time. Plotting them one by one is not a problem. There appears to be a specific point in time (different for the two participants) when this goes wrong. If I avoid that time (by using cfg.xlim) it works fine. My trials have different lengths and I used "cfg.vartrllength = 2;" when calling ft_timelockanalysis (not sure whether this is relevant). The error message I get is "Subscripted assignment dimension mismatch Error in ft_multiplotER (line 616) yval(i,:) = datamatrix{i}(m,:);" The timeline of both averages is different, but they both go from at least -2.5 to + 4 seconds. Even if I use cfg.xlim - [-2.5 4]; it gives this error message (this does not happen for averages of other subjects, I do not see a difference).


Sara Bögels - 2013-07-18 13:51:44 +0200

In the newest version of Fieldtrip the line in ft_multiplotER should be 638.


Jan-Mathijs Schoffelen - 2013-10-10 10:58:48 +0200

Assigned to a named person, to push forward the resolution of this bug. Otherwise it just adds to the 'stuwmeer' of unassigned bugs, that nobody feels responsible for. @Nietzsche: Feel free to discuss how to tackle a problem like this.


- 2013-10-17 18:26:18 +0200

As mentioned in the last comment of Bug2160 by roboos: "Note that ft_multiplotER still does not support multiple inputs with different time axes (or freq axes), but at least it gives a useful error. If in the future we do want to have this functionality, it should be done using a single call to ft_selectdata with all input args, as ft_selectdata knows how to trim data to consistent selections along any dimension (also time and freq)". So, since Sara's data have different time ranges it leads to ft_multiplotER to crash. Using cfg.vartrllength = 2 is probably the cause of having different time ranges, however, users should be allowed to do this for there data, so we should just implement flexibility into ft_multiplotER. As this bug was filed PRIOR to the changes made in response to bug2160, there is not already a check built into the beginning of ft_multiplotER that insists for equal time axes for all input data structures. If we want to build in flexibility then we should: (1) take advantage of this code: % ensure that all inputs are sufficiently consistent if hastime && ~checktime(varargin{:}, 'identical', cfg.tolerance); error('this function requires identical time axes for all input structures'); end if hasfreq && ~checkfreq(varargin{:}, 'identical', cfg.tolerance); error('this function requires identical frequency axes for all input structures'); end (2a) when inputs are inconsistent, call ft_selectdata and trim the longer dataset(s) to have the time/freq axes be the same as the maxmin of the shortest dataset(s). (2b) when inputs are inconsistent, lengthen (pad with zeros?) shorter dataset(s) to have the time/freq axes be the same as the maxmin of the longest dataset. I think it's important to have option B. If the user decides to use trials of variable length, then it is probably important to look at time points of the longer trial(s). Can I get some input on this?


Sara Bögels - 2014-01-22 11:17:05 +0100

Hi, I just found out that a newer version of Fieldtrip now indeed gives the error message that 'this function requires identical time axes for all input structures'. However, an earlier version did work for slightly different (but very similar) time axes (e.g., -.2010 vs -.2008 as staring point). So, it seems this problem has become worse...? Or would it be problematic to plot the two data structures together using the early Fieldtrip version? Sara


- 2014-01-22 11:24:44 +0100

(In reply to Sara Bögels from comment #4) Hi Sara, yes, I wanted to work on this earlier, and I emailed to ask you for a sample dataset but I never heard from you so I've left this bug on hold as no one else has reported this problem. So, I just implemented a new warning message that you need to have plots with the same time scale, and put priority on some other bugs. Sorry about that :(. For the -.2010 vs. -.2008, I think this might work for matlab because it might be rounding the values to -.2, so there's some leeway there. I'm not entirely sure but I'll look into it. I don't think there's an issue using an earlier version of FieldTrip, but I don't think there should be a difference, at least not withing this plotting function, because the code hasn't been changed. I'll get back to you later today, as we have an FT meeting where I can ask about this. In the mean time, could you please send me your dataset?


Jan-Mathijs Schoffelen - 2014-02-12 14:03:51 +0100

Discussed in FT-meeting: A more generic solution was discussed, where the requested functionality seems to be coincident with wishing for a 'union' rather than an 'intersect' in ft_selectdata. Suggestion: JM takes over and implements this in ft_selectdata. Once this is in place the plotting functions should support the specification of the 'union' switch (and call ft_selectdata on the multiple input arguments).


Jan-Mathijs Schoffelen - 2014-02-14 15:55:59 +0100

apparently the shift between the time axes is larger than the default tolerance.


Jan-Mathijs Schoffelen - 2014-02-26 13:18:35 +0100

change cfg.selmode into cfg.select in ft_selectdata_new


Jan-Mathijs Schoffelen - 2014-05-19 09:43:39 +0200

As was discussed in the FT-meeting at some time, we're not going to fix this at the moment. Apologies for the change in behavior, but currently we would expect the users to make sure that the input arguments have matching time axes.