Back to the main page.
Bug 2398 - merge the functionality of ft_leadfield_openmeeg into the regular fieldtrip functions
| Status | ASSIGNED |
| Reported | 2013-11-29 10:01:00 +0100 |
| Modified | 2015-02-11 10:43:08 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2338 |
| See also: |
Robert Oostenveld - 2013-11-29 10:01:34 +0100
ft_leadfield_openmeeg makes a BEM model from meshes (after mesh validation) and computes the leadfield for a large number of dipole locations. The useful and improved functionality should be redistributed over ft_prepare_headmodel -> check the meshes ft_headmodel_openmeeg -> make the BEM model ft_prepare_vol_sens -> project the electrodes, make temporary files(?) ft_compute_leadfield -> compute the leadfield (one dipole at a time, or multiple dipoles in one go) ft_prepare_leadfield -> do data bookkeeping, channel selection etc., compute leadfields for many dipoles
Robert Oostenveld - 2013-12-05 11:59:13 +0100
only one more to go... @Daniel: could you outline what ft_leadfield_openmeeg is doing differently than ft_compute_leadfield/openmeeg_megm? I know that in ft_prepare_leadfield (the high-level function) there is an alternative way of looping over dipoles for openmeeg to make it more efficient, this is something Cristiano coded. But the main question pertains to the computational aspects, not the organizational aspects. Are the leadfields any different?