Back to the main page.

Bug 3317 - ft_singleplotTFR and ft_multiplotTFR show useless warnings

Status	REOPENED
Reported	2017-06-21 15:36:00 +0200
Modified	2019-04-02 12:06:07 +0200
Product:	FieldTrip
Component:	plotting
Version:	unspecified
Hardware:	PC
Operating System:	Linux
Importance:	P5 trivial
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

---

Daniel Matthes - 2017-06-21 15:36:27 +0200

If I call ft_singleplotTFR or ft_multiplotTFR with data containing a trialinfo, I got the following warning. Warning: could not determine dimord of "trialinfo" in: label: {64×1 cell} dimord: 'rpt_chan_freq_time' freq: [1×49 double] time: [1×345 double] powspctrm: [1×64×49×345 double] cumtapcnt: [49×1 double] trialinfo: 100 cfg: [1×1 struct] > In getdimord>warning_dimord_could_not_be_determined (line 621) In getdimord (line 572) In ft_selectdata (line 201) In ft_freqdescriptives (line 132) In ft_singleplotTFR (line 190) On my opinion, it should not appear because the trialinfo variable has nothing to do with the dimension of the powspctrm array. But I'm not really sure, how to fix it, therefore I report this behavior as a bug.

---

Robert Oostenveld - 2017-06-22 20:08:23 +0200

the error indicates that getdimord is not smart enough. It should know what the dimensions of trial info are (I even know this from the top of my head: it is "rpt_other") Can you suggest a fix/PR for getdimord?

---

Robert Oostenveld - 2017-06-22 20:09:24 +0200

hmm, it is a weird structure, since it has a single trial.

---

Arjen Stolk - 2017-08-25 18:45:51 +0200

Just backing up this observation. getdimord warnings are ubiquitous, and sometimes fields (e.g. fourierspctrm) disappear in relation to the warning. I assumed this is work in progress, but if not, let me know so I could start collecting/simulating the issues as I go.

---

Jan-Mathijs Schoffelen - 2019-04-01 08:59:54 +0200

Daniel/Arjen, does this need to be followed up? If so, please suggest a way forward by means of a PR, as per Robert's suggestion.

---

Arjen Stolk - 2019-04-01 09:06:20 +0200

(In reply to Jan-Mathijs Schoffelen from comment #4) Haven't observed this behavior in a while, so closing this issue

---

Daniel Matthes - 2019-04-02 10:28:48 +0200

The warning is still existing. I will try to create a fix, when I find the time.

---

Robert Oostenveld - 2019-04-02 12:06:07 +0200

the detection of dimord is (has been) improving over time. Whenever I encounter a case that annoys me, I always try to to improve hte getdimord function. "private/getdimord.m" line 424 now has case {'sampleinfo' 'trialinfo' 'trialtime'} if isequalwithoutnans(datsiz, [nrpt nan]) dimord = 'rpt_other'; end which I think should deal with the specific one. However, using "git blame" I see that this piece of code is already present since 2014. So apparently something is wrong .... Ah, I see that the data structure is internally not consistent. The field freq.cumtapcnt should be ntrials*1, which suggests that the data consists of 49 trials, whereas powspctrm and trialinfo show that it is only contains a single trial. Please try the following with freq.cumtapcnt commented out or not: ------------ freq = []; for i=1:64 freq.label{i} =num2str(i); end freq.freq = 1:49; freq.time = 1:345; freq.powspctrm = randn(1, 64, 49, 345); % freq.cumtapcnt = ones(49,1); freq.trialinfo = 100; freq.cfg = []; cfg = []; cfg.avgoverfreq = 'yes'; cfg.avgovertime = 'yes'; freq_avg = ft_selectdata(cfg, freq); ------------ The question then is: Where does this incorrect freq.cumtapcnt come from?