Back to the main page.
Bug 1029 - fix inconsistent naming of forward solutions
| Status | CLOSED FIXED |
| Reported | 2011-10-10 14:54:00 +0200 |
| Modified | 2012-10-29 13:44:59 +0100 |
| Product: | FieldTrip |
| Component: | forward |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-10-10 14:54:41 +0200
nolte/singleshell bem_cp/bemcp bem_openmeeg/openmeeg bem_asa/asa bem_dipoli/dipoli what is bem by itself in ft_voltype?
Cristiano Micheli - 2011-11-16 18:52:09 +0100
(In reply to comment #0) correct also the definitions in ft_voltype by adding a check that grants backward compatibility
Cristiano Micheli - 2012-02-01 16:07:43 +0100
(In reply to comment #1) This implies a better documentation of ALL forward solutions (headmodel contained in 'vol', created by ft_prepare_headmodel, assigned by ft_voltype, and documented/checked for backward compatibility in ft_datatype_headmodel) The string to create it should be documented in ft_voltype. Make a list of all of them and their fields according to the current version, then check their compatibility and report it in ft_datatype_headmodel
Cristiano Micheli - 2012-02-01 16:09:15 +0100
(In reply to comment #2) add also the name of the links to create the headmodels from the wiki
Cristiano Micheli - 2012-02-15 14:38:39 +0100
(In reply to comment #3) Some questions arise from a first attempt to tackle this issue: - the new ft_prepare_headmodel routine calls the bem models with the new convention (e.g. bem_xxx) whereas the low level functions assign a vol.type that follow the old conventions. This should be changed without impacting the functionality (test files). - a check about the consistency of old/new vol structures is added in ft_datatype_headmodel. The version of december 2011 is considered the newest one, but when changes about the method's names will be applied there will be a need for a '2012' version in this function. How does fieldtrip check the actual running version? - ft_voltype determines the type of a volume conductor structure but the list is incomplete (halfspace, fem/fdm models absent) - the ft_datatype_xxx checks the compliance of created vol structures with the routines that take them as inputs (ft_prepare_vol_sens.m ft_computeleadfield etc.) At the moment the function is work-in-progress but will have to be added before performing any operation with the vol structures.
Gio Piantoni - 2012-02-20 09:11:40 +0100
(In reply to comment #4) Hey, very quick follow-up on this: r5295 transforms 'dipoli' into 'bem_dipoli' in ft_datatype_headmodel. So the vol.type is converted to the new type. However, ft_prepare_vol_sens.m, line 403, expects the "old" names. Is it ok to change: {'bem', 'dipoli', 'asa', 'avo', 'bemcp', 'openmeeg'} into: {'bem', 'bem_dipoli', 'bem_asa', 'bem_avo', 'bemcp', 'bem_openmeeg'} Should I do it?
Cristiano Micheli - 2012-03-01 00:52:06 +0100
(In reply to comment #5) Hi, I fixed it. It required a more extensive intervention on numerous routines. C
Robert Oostenveld - 2012-07-03 15:23:43 +0200
On 3 Jul 2012, at 13:06, Johanna Zumer wrote: Hi Robert, I noticed you made some big changes to ft_datatype_headmodel in the past 24 hours. It's fine except on lines 71-72: if strcmp(vol.type, 'concentric') vol.type = 'concentricspheres'; which causes problems later on, as vol.type = 'concentric' is expected, not 'concentricspheres'. I assume this is just a typo mistake, not intended? Shall I fix it? Cheers, Johanna
Robert Oostenveld - 2012-07-03 15:33:56 +0200
(In reply to comment #7) This pertains to bug 1580 comment 3 and further. There was still a large inconsistency in the code, documentation and data representation. I have decided that all vol.type=xxx strings should match the corresponding ft_headmodel_xxx functions. That means short names for the bem, fem and fdm methods (no _bem_something) and concentricspheres rather than concentric. I have made the following change restructuring - more changes towards realizing consistent naming of vol.type in code, documentation and data representations, see also bug 1580 and 1029 manzana> svn commit `cat out` Sending fileio/private/ft_convert_units.m Sending forward/ft_compute_leadfield.m Sending forward/ft_convert_units.m Sending forward/ft_headmodel_asa.m Sending forward/ft_headmodel_bemcp.m Sending forward/ft_headmodel_concentricspheres.m Sending forward/ft_headmodel_dipoli.m Sending forward/ft_headmodel_fns.m Sending forward/ft_headmodel_openmeeg.m Sending forward/ft_headmodel_simbio.m Sending forward/ft_inside_vol.m Sending forward/ft_prepare_vol_sens.m Sending forward/ft_sourcedepth.m Sending forward/ft_voltype.m Sending ft_prepare_concentricspheres.m Sending ft_prepare_mesh.m Sending ft_prepare_mesh_new.m Sending inverse/private/ft_inside_vol.m Sending plotting/ft_plot_vol.m Sending utilities/ft_datatype_headmodel.m Transmitting file data .................... Committed revision 6211. please let me know if you encounter incompatibilities
Robert Oostenveld - 2012-08-08 18:14:03 +0200
I noticed that vol.type could still be nolte instead of singleshell. I have changed that in the following functions. manzana> svn commit `cat out` Sending forward/ft_compute_leadfield.m Sending forward/ft_headmodel_singleshell.m Sending forward/ft_inside_vol.m Sending forward/ft_prepare_vol_sens.m Sending forward/ft_sourcedepth.m Sending ft_prepare_singleshell.m Sending plotting/ft_plot_vol.m Sending private/headsurface.m Sending test/test_bug131.m Sending test/test_spm_ft_integration.m Sending utilities/ft_datatype_headmodel.m Transmitting file data ........... Committed revision 6344. and one more... manzana> svn commit external/openmeeg/openmeeg_meg_leadfield_example.m Sending external/openmeeg/openmeeg_meg_leadfield_example.m Transmitting file data . Committed revision 6346. the only function that still knows about type=nolte is ft_datatype_headmodel, which takes care of the backward compatibility support.
Robert Oostenveld - 2012-09-19 23:57:40 +0200
I believe this one to be resolved by now. If not, please let me know!