[FieldTrip] Source reconstruction - low-rank leadfield

Diego Lozano-Soldevilla dlozanosoldevilla at gmail.com
Tue Oct 20 13:40:16 CEST 2020


Thanks a lot Jan-Mathijs,

I'm going to join forces with Tibor and we'll file the PR if needed ;)
Best
Diego

On Tue, Oct 20, 2020, 13:14 Schoffelen, J.M. (Jan Mathijs) <
jan.schoffelen at donders.ru.nl> wrote:

> Hi Tibor,
>
> Let me deliberately ignore your follow up questions for now, and focus on
> the grand scheme of things, and ask a question back:
>
> using the simbio headmodel, and the (it seems) cortically constrained
> source model as an input to ft_prepare_leadfield, does this result in
> dipoles which are inconsistently classified as ‘inside’, (as having a
> ’true’ for the corresponding entry in the inside-field) while the
> corresponding entry in the lead field cell-array is empty?
>
> If so, this needs to be fixed, because it is incorrect behavior of the
> fieldtrip code. Again, looking forward to a PR that fixes this (possible)
> issue.
>
> Best wishes,
>
> Jan-Mathijs
>
>
> On 20 Oct 2020, at 11:44, tibor.auer at gmail.com wrote:
>
> Dear Diego and Jan-Mathijs,
>
> Thank you for your valuable input.
>
> I am using simbio headmodel with 5 tissue compartments.
>
> I have looked into the code and data, and Jan-Mathijs’ suspicion is
> correct. I have attached a figure, which shows the location of the 0-ranked
> leadfield on the sourcemodel, and they are indeed mostly ‘outside normal
> brain’ (i.e. ventricles and one spot just outside the cortex).
>
> Based on that, I think it is safe to exclude these locations. However, I
> wonder how these exlcusions might affect the analysis. Does it mean that I
> will not have an estimate for the affected locations, or will they be
> interpolated? If the former, then will these locations automatically
> excluded during group analysis, or do I have to explicitly exclude them?
>
> I understand that the locations I am showing on the attached figure are
> not of interest anyway.
>
> Kind regards,
> Tibor
>
> *Auer, Tibor M.D. Ph.D.*
> tibor.auer at gmail.com
> +44-7906-863837
> @TiborAuer
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FTiborAuer&data=02%7C01%7Ct.auer%40surrey.ac.uk%7C0da68a9196be4a4fd60108d71a70e11e%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637006944417188277&sdata=aoE%2FhNWj%2F%2F3L8fDDz4S0dMuMTlt2p05mgHaDTXddP4w%3D&reserved=0>
>
> *From:* fieldtrip <fieldtrip-bounces at science.ru.nl> *On Behalf Of *Schoffelen,
> J.M. (Jan Mathijs)
> *Sent:* 20 October 2020 09:49
> *To:* FieldTrip discussion list <fieldtrip at science.ru.nl>
> *Subject:* Re: [FieldTrip] Source reconstruction - low-rank leadfield
>
> Hi Tibor, and Jefe,
>
>
> I guess that the road to a solution starts by looking into the code, and
> inspecting what line prompts the error (let me give this one away: line 145
> in ft_inverse_eloreta).
>
> Also, it might be useful to consider not only the source model, but also
> the volume conduction model, and the method that was used for the forward
> computation. This was not mentioned in your messages, so it is hard to
> comment on that.
>
> Then, it may make sense to think about what matrix gives a rank of 0.
> Typically, the only way in which matlab returns a 0, is in the case of an
> empty matrix.
>
> Thus, the suspicion will rise that the eloreta code is trying to operate
> on dipole positions for which the corresponding leadfield is an empty
> matrix.
>
> The latter typically occurs if that dipole position is considered to be an
> ‘outside’ position in the forward computation step, e.g. when it is
> ’sticking out’ of the brain compartment boundary of the volume conduction
> model (but again, given the lack of details about the specifics of the
> volume conduction model etc., this is mere speculation, causing me to
> already type and think about this for longer than is probably necessary (in
> case the above is not true) ).
>
> Then, the overall question might boil down to the question: why does the
> forward computation consider some dipoles to be outside (i.e. not returning
> a leadfield matrix for those locations), and why does the inverse
> computation code (at least for particular method) not take that into
> account?
>
> Assuming that all my speculations above are valid, a principled solution
> will lie in ensuring that the eloreta code only considers the dipole
> positions with a valid lead field matrix.
>
> I am looking forward for a PR that addresses this.
>
>
> Best wishes,
>
> Jan-Mathijs
>
>
>
> On 20 Oct 2020, at 10:26, Diego Lozano-Soldevilla <
> dlozanosoldevilla at gmail.com> wrote:
>
> Dear Tibor and FieldTrippers
> I'm in the same situation. I excluded those positions but now I'm
> wondering whether this was a good decision. If somebody know what's
> happening and how to fix this, please drop a line!
> Yours sincerely,
> Diego
>
>
>
> On Mon, 19 Oct 2020 at 20:17, <tibor.auer at gmail.com> wrote:
>
> Dear FieldTrippers,
>
> I have some questions regarding source reconstruction.
>
> We use eLORETA, which runs fine for most participants, however, I receive
> this error message for quite a few:
>
> *the forward solutions have a different rank for each location, which is
> not supported*
>
> The rank of the leadfdield is reduced at each sourcemodel position to the
> default 3. However, it sometimes has an even lower rank (often 0) at
> certain sourcemodel positions, and I am not sure how to interpret it. We
> use a cortical sheet based sourcemodel, and I have noticed that only a
> handful (<<1%) of positions are affected. My educated guess would be to
> exclude those positions, but I am not sure how it affects the analysis,
> either.
>
> Kind regards,
> Tibor
>
> *Auer, Tibor M.D. Ph.D.*
> *Research Fellow*
> *School of Psychology, Faculty of Health and Medical Sciences*
> University of Surrey, Guildford GU2 7XH
> T.Auer at surrey.ac.uk
> @TiborAuer
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FTiborAuer&data=02%7C01%7Ct.auer%40surrey.ac.uk%7Cdb32da458c424eedef2908d7d4bd1421%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637211780868086968&sdata=zrT5%2FnGGsar14C3WartuU99tzsfLu30Peh9fuaqrAUg%3D&reserved=0>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> <diagnostic_aamod_meeg_sourcereconstruction_leadfieldrank.jpg>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201020/a08fdf21/attachment.htm>


More information about the fieldtrip mailing list