Including HArtMuT source model into leadfield creation

[DanielMiklody]

We have implemented a head modeling approach that includes muscle and eye sources using fieldtrip and OpenMEEG.
It also offers the possibility to model muscles as tripolar sources which is a more realistic EMG model.

We would like to include that as a feature into fieldtrip.
OpenMEEG merging is still on the way and is needed for this code to run.

This issue is the related paper:
https://iopscience.iop.org/article/10.1088/1741-2552/aca8ce

[DanielMiklody]

few initial considerations by Jan Mathijs:

• as I understand it, the key functionality that hartmut requires, is the creation of an ‘extended’ forward model, which includes a model of the eye balls, and a model of a bunch of tripolar muscle sources.
• right now the bulk of the changes is suggested in the low level ft_compute_leadfield, which I feel is a bit ad hoc, and might be better dealt with at a higher level in the code. For instance, conceptually one could create a compound source model, by concatenating (outside the lower level function calls) a triplet of source models, i.e. the leadfield obtained for the brain dipoles, with the leadfield obtained for the (symmetric) eye dipoles, with the leadfield obtained for the muscular components. Is there a particular reason why you didn’t opt for that route? I think that from the FieldTrip point of view, this would have our preference.
• a PR should be accompanied by a test function, demonstrating the new functionality (and ideally also demonstrating that nothing else is broken by the code changes)
• FieldTrip does not strongly impose strong checks on the version compatibility of external toolboxes (such as openmeeg), perhaps some checks and balances are required because users might have mismatching versions of the code (fieldtrip vs. openmeeg), and hartmut requires the latest openmeeg code.

[DanielMiklody]

• right now the bulk of the changes is suggested in the low level ft_compute_leadfield, which I feel is a bit ad hoc, and might be better dealt with at a higher level in the code. For instance, conceptually one could create a compound source model, by concatenating (outside the lower level function calls) a triplet of source models, i.e. the leadfield obtained for the brain dipoles, with the leadfield obtained for the (symmetric) eye dipoles, with the leadfield obtained for the muscular components. Is there a particular reason why you didn’t opt for that route? I think that from the FieldTrip point of view, this would have our preference.

We mainly used ft_dipolefitting through EEGlabs dipfit for the source localization an this calls ft_compute_leadfield. We did not see another way but including it the way it is without rewriting everything. I do agree that a higher-level implementation makes sense, though.

[DanielMiklody]

on the rest of your comments, we are working, @schoffelen. Thank you

[schoffelen]

• right now the bulk of the changes is suggested in the low level ft_compute_leadfield, which I feel is a bit ad hoc, and might be better dealt with at a higher level in the code. For instance, conceptually one could create a compound source model, by concatenating (outside the lower level function calls) a triplet of source models, i.e. the leadfield obtained for the brain dipoles, with the leadfield obtained for the (symmetric) eye dipoles, with the leadfield obtained for the muscular components. Is there a particular reason why you didn’t opt for that route? I think that from the FieldTrip point of view, this would have our preference.

We mainly used ft_dipolefitting through EEGlabs dipfit for the source localization an this calls ft_compute_leadfield. We did not see another way but including it the way it is without rewriting everything. I do agree that a higher-level implementation makes sense, though.

Awww! I didn't think of that. Good point. But this prompts the question: are the locations of the interfering sources (i.e. eye, muscle) static? (obviously I didn't read the paper in detail yet)

[DanielMiklody]

no they aren't static, they are added to the head model: Our solution was to set all the parameters as fields in the vol struct. We should probably also add a short tutorial how to change parameters etc?!