[FieldTrip] Fwd: correct way to read Elekta fiff-files

Fri Dec 9 08:25:23 CET 2022

Begin forwarded message:

From: Michael Scholz <michael.scholz at med.ovgu.de<mailto:michael.scholz at med.ovgu.de>>
Subject: Re: [FieldTrip] correct way to read Elekta fiff-files
Date: 8 December 2022 at 17:53:11 CET
To: "Schoffelen, J.M. (Jan Mathijs) via fieldtrip" <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Cc: "Schoffelen, J.M. (Jan Mathijs)" <janmathijs.schoffelen at donders.ru.nl<mailto:janmathijs.schoffelen at donders.ru.nl>>

Dear Jan-Mathijs,

best thanks for your detailed answer. Things are quite clear now.

I'll use the coilaccuracy=0 setting for my project to export
fieldtrip-data-structure to Curry8.
However, it seems that Curry uses a further different way to model
the position and orientation of gradiometer-coils beneath those ways
you mentioned according to coilaccuracy=[] or =0.

Good to know, that I can ignore the warnings in case of coilaccuracy=[]. Though read data seemed to be ok, there was a annoying sense remaining
that something went wrong.

I'm not sure if I'll be able to formulate a documentation text for
coil-accuracy in sufficiently precise and general terms.

best regards,
Michael Scholz

On Mon, 5 Dec 2022, Schoffelen, J.M. (Jan Mathijs) via fieldtrip wrote:

Hi Michael,

First of all, it is important to make a distinction between channels and coils. In FieldTrip speak, coils refer to the pick-up coils, i.e. the things through which a current starts flowing which is proportional to the magnetic field strength orthogonal to the plane of the coils. Channel positions are needed typically for visualization, and coil positions (+orientations) are needed for forward/inverse modelling.
A magnetometer consists of a single coil, and it is straightforward to have a one-to-one mapping between the coil and its corresponding channel position.
A gradiometer consists of a pair of coils, which, in case of a Megin/Elekta system, lie pairwise in a plane, in order to capture the magnetic field?s gradient along the direction of the vector that connects the two coils. Typically, a gradiometer channel?s position can be thought of as the average of the constituent coils? centres. Anyway the long story short is that the coils that belong to a gradiometer channel have different positions than the (single) coil that belongs to a magnetometer channel (of the same triplet of channels).
Now, when modelling a forward field, one could work with the assumption that the magnetic field through the coils is locally homogeneous, which allows for only a single point estimate per coil (typically in its centre). This will implicitly happen when reading in the sensor information from the fif-file, using coil_accuracy=0, or coil_accuracy=[]. When coil_accuracy is >=1, each coil will be described by more than a single position/orientation, which allows for a more fine grained model of the field through the coils. For Megin/Elekta systems, the coil_accuracy parameter is handled in the function mne2grad. The difference between [], and 0 relates to two different ways in which the coil positions/orientations/units will be computed. The historically older [] option uses a slightly different computation than the ?newer? 0/1/2 options. The latter uses (an increasingly more sophisticated description of the coils) from the coil_def file, which we obtain from the mne-python folks. If I recall well, the difference between the [] option and the 0 coil_accuracy is an offset of the position of 0.3 (something)m into the z-direction (i.e. orthogonal through the plane of the coil, probably intended to account for the thickness of the coil or so). I am not sure whether this will have an appreciable effect on the modelled fields later on. But either way, I?d recommend to work with a numeric value (can be 0) for coil_accuracy in your case, because it will return the sensor-array description (which includes not only positions and orientations, but also a balancing matrix called tra) in SI-units, which will make the interpretation of the physical units easier down the road + the combination between gradiometers and magnetometers more straightforward (hence the warnings that your mentioned in your message: they are not a show stopper by the way, but merely warnings).

I am not aware of coil_def files that make a distinction between triux and vectorview coils, nor whether there is a difference between them.

There is this documentation page: https://urldefense.com/v3/__https://www.fieldtriptoolbox.org/faq/coilaccuracy/__;!!HJOPV4FYYWzcc1jazlU!8S_vhAG3cjdZWpn4pYM5rMh9er3X-GekfygkwbRgmE9MzNA7MTBuKzGkhVAv19G4al5HOJ3sV7b0KocCc1Uq6EVmO1zKUaXaSQMJM68EQCro$  which somebody at some point created, but which does not have any content right now. Feel free to fill it with some of the information given above, so that it is documented a bit more persistently for posterity. You can submit your suggestion as a PR on github: https://urldefense.com/v3/__https://github.com/fieldtrip/website__;!!HJOPV4FYYWzcc1jazlU!8S_vhAG3cjdZWpn4pYM5rMh9er3X-GekfygkwbRgmE9MzNA7MTBuKzGkhVAv19G4al5HOJ3sV7b0KocCc1Uq6EVmO1zKUaXaSQMJM6hE7yT1$
Best wishes,
Jan-Mathijs

On 1 Dec 2022, at 12:26, michael.scholz--- via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear community,
this is Michael Scholz from Universitätsklinik für Neurologie, Otto-von-Guericke-Universität Magdeburg.
We are working with EEG- and MEG-data from Neuromag/Elekta/Megin fif-files.
We have a Triux-system with 306 MEG-sensors installed in 2016;
Internal Active Shielding (IAS) is off,  Maxfilter is used always.
I'm working on a matlab-routine to export preprocessed EEG- and MEG-data from fieldtrip
to Compumedics Neuroscan Curry 8, which is our standard tool for source analysis.
There is some incongruity with reading fif-file by fieldtrip.
Right by reading header-info by ft_read_header(fifname) I get a lot of warnings:
% Warning: assuming that the default scaling should be amplitude/distance rather than amplitude
%  In ft_datatype_sens at line 325
%  In ft_datatype_sens at line 207
%  In ft_datatype_sens at line 180
%  In ft_read_header at line 2841
I tried to localize the source of this warnings, but I finally failed in some sub-sub-sub-routine.
It seems, reading header has kind of inconsistency, however, results of reading data seem to be fine.
I now (by chance) found the option 'coil_accuracy' for ft_read_header.
Calling it with value 0 for 'coil_accuracy' works fine, since there aren't warnings any more.
I also compared the resulting values of location and orientation of sensors with the data
I get from Curry's cdt/dpa-files, if I read and export the fif-file within Curry.
With coil_accuracy=[], I get deviation of gradiometer-positions of up to 0.3mm;
with coil_accuracy=0, I get deviation of gradiometer-positions of up to 0.00003mm,
but only after adaption of gradiometer-position-pair-means to magnetometer-position.
What is the correct way to read our fif-files into ft?
In MNE's coil_def.dat for sensor coil-type id 3024 for magnetometer and 3012 for gradiometer
there are "vector-view"-entries only, but no entry for "triux".
Is there a difference?
Is possibly the used coil_def.dat not up-to-date?
#       mne_list_coil_def version 1.12 compiled at Jul 12 2016 18:39:09
Did I miss to read a piece of ft-documentation, which answers this questions,
especially about the usage of coil-accuracy?
with best regards,
Michael Scholz
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!6cfYuQ_Vcfw-aQuPXx4KgOiGSzkmnhd_oH_1XQ1n_ZtaOwwrSn61x1wBgOeiDd-S5_bdlZOfScnUqNbYuPWZ87cZayBsaasx6K9Nrg$

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!8S_vhAG3cjdZWpn4pYM5rMh9er3X-GekfygkwbRgmE9MzNA7MTBuKzGkhVAv19G4al5HOJ3sV7b0KocCc1Uq6EVmO1zKUaXaSQMJM0m9-78u$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20221209/b4ba61e0/attachment-0001.htm>