Back to the main page.

Bug 2824 - implement Harmony: Source Reconstruction in the Anatomical Basis of Spherical Harmonics

Reported 2015-02-03 16:32:00 +0100
Modified 2020-07-02 13:04:07 +0200
Product: FieldTrip
Component: inverse
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Luca Ambrogioni
Depends on:
See also:

Robert Oostenveld - 2015-02-03 16:32:29 +0100

see the implementation should be consistent with the data handling now used in disc and plc (for complex valued data) and with mne (now only for real valued data, but see #2822). I suggest to start with a (non-functional) test script that details the architecture of the source code that is exposed to the user. It would best start from some mat files and some simulated data. I.e. something like load headmodel.mat % from ft_prepare_headmodel load sourcemodel.mat % from ft_prepare_sourcemodel, where the input is a FS mesh data = ft_dipolesimulation(...) erf = ft_timelockanalysis(...) cfg = ... source = ft_sourceanalysis(cfg, erf) This should clarify how the data is handled and how the various options (=design choices) are dealt with, prior to implementing low-level code. Once the architecture is clear, the low-level implementation can follow.

Jan-Mathijs Schoffelen - 2020-06-20 21:38:34 +0200

the current implementation of harmony sucks. That is, it does not work from the shelf using frequency domain data, even though it is suggested in the help of ft_sourceanalysis. I will try to see if it can be fixed with minimum effort. If not, I will disable this functionality from ft_sourceanalysis, unless Luca wants to fix this. See the code in the PR1456 on github:

Jan-Mathijs Schoffelen - 2020-06-20 21:46:01 +0200

symptoms: harmony.m calls ct_mesh_spectrum which does not exist, it seems that mesh_spectrum exists, so I change that; default parameters are not specified, and the function errors if parameters are empty (which happens if the user doesn't specify this).

Jan-Mathijs Schoffelen - 2020-06-20 21:47:24 +0200

Also, the function does not check whether the input sourcemodel contains a triangulatied mesh, rather than e.g. a 3D grid, or a random cloud of points in 3D space.

Jan-Mathijs Schoffelen - 2020-07-02 08:50:23 +0200

Currently, the contributed code is dysfunctional, and since the stakeholders don't seem to care about this, I will close this. No reason to keep it open, nor to spend time on it.

Robert Oostenveld - 2020-07-02 12:56:13 +0200

should we delete the function and the corresponding failed_bug_harmony.m test script?

Jan-Mathijs Schoffelen - 2020-07-02 13:04:07 +0200

(In reply to Robert Oostenveld from comment #5) Perhaps this is a question to be answered by Eric and Luca, since they are the main stakeholders here. If they'd like to invest into getting the function functional again + write some documentation about how to use it, it may still be an asset to the codebase.