Q about integration with SPM8

Tue Jan 13 00:40:39 CET 2009

Dear John,

It's hard for me to follow your reasoning. On the one hand you want to
keep using your old 'tweaked'  FT, but on the other hand you want to
switch to SPM's version which would not contain your modifications.
Maybe there is something basic that I should reiterate. The actual
analysis done in SPM is different than the analysis in FT. SPM proper
presently used code from FT for data conversion and for computing lead
fields. In both cases there are unlikely to be different results for
different versions of the code.

The reason all of FT is included in SPM and not just those specific
parts is to make it possible for people to write some custom tools
combining SPM and FT functions and distribute them to SPM users
without the need to install external FT.  If you just want to do your
own analysis I don't see a good reason for you to use the FT included
in SPM rather than the version you are presently working with.

What I suggest is - just put both your old FT and SPM in the path and
see how it goes. I don't foresee any problems. Note that you should
keep updating SPM with patches from
ftp://ftp.fil.ion.ucl.ac.uk/spm/spm8b_updates/

Best,

Vladimir

On Mon, Jan 12, 2009 at 11:04 PM, John Iversen <iversen at nsi.edu> wrote:
> Sorry, my reply just crossed with yours. Ok, I'm now a bit confused as to
> the specifics of the co-evolution of the two projects. It sounds like the FT
> in SPM is a custom fit good at a particular moment in time, but that
> separate changes in either SPM or FT could bring some conflicts. That seems
> like a good argument to use the SPM version of FT.
>
> To clarify my perspective, what I didn't note in my original email, and I
> should have, is that the 'headache' I referred to is mainly due to the fact
> that I've made some modifications of my own on FT, and wasn't keen to need
> to fold them into two separate versions of FT that might be updated at
> different times. Granted that's a self-inflicted headache and perhaps at
> this point I should reconsider whether those modifications are in fact
> necessary. More generally, though, I like to tweak and be familiar with
> every detail of the code I'm using, so having two different versions is just
> that much more for my finite brain to keep track of.
>
> Of course, more generally the number one issue would be to avoid a situation
> in which two versions yielded different analysis results, but that doesn't
> seem to be a concern that either of you have expressed, so perhaps that is
> not something to worry about.
>
> So, now I'm considering just using the version of FT included in SPM for all
> my uses. I don't take advantage of the daily upgrades to FT, so the slower
> release schedule is fine. How does that sound?
>
> Thanks,
>
> John
>
> On Jan 12, 2009, at 2:13 PM, Vladimir Litvak wrote:
>
>> Although what Robert described (deleting the private subdirectories)
>> will do the trick, I don't see any reason to do it. I do see a reason
>> not to do it because it may generate errors that will be very hard for
>> us to reproduce and resolve. We are now often developing things in
>> parallel where changes are made to FT to make some SPM feature work so
>> if the two get slightly out of sync those new features will not work.
>> Thus, I repeat my recommendation to leave things as they are. Don't
>> you agree, Robert?
>>
>> There might be some problems with clashes if Robert starts naming some
>> FT functions with the same names as wrappers in SPM. I don't know if
>> there are any cases like this already.
>>
>> Vladimir
>>
>>
>>
>> On Mon, Jan 12, 2009 at 8:12 PM, Robert Oostenveld
>> <r.oostenveld at fcdonders.ru.nl> wrote:
>>>
>>> Hi John,
>>>
>>> Vladimir and I (and other spm developers) have considered this carefully,
>>> and the present spm8+fieldtrip mixture was the best we could come up
>>> with.
>>> The versions are automatically kept in synch, but the release schedule of
>>> fieldtrip is daily, whereas for spm8 it is less frequent. So the versions
>>> getting slightly out of sync on your computer is inevitable.
>>>
>>> With the latest 2008a and 2008b versions of Matlab there are better
>>> options
>>> for supporting such mixtures ofg packages (using "namespaces"), but since
>>> both spm and fieldtrip should work on older matlab versions, we cannot
>>> use
>>> those features yet.
>>>
>>> On 9 Jan 2009, at 19:31, Vladimir Litvak wrote:
>>>
>>>>> To avoid this issue,
>>>>> I was planning to have SPM8 use my existing Fieldtrip installation
>>>>> exclusively. Is there is any downside to this?
>>>>
>>>> Yes because there is no guarantee that your particular FT version is
>>>> compatible with your SPM version (unless you keep updating both which
>>>> is redundant).
>>>>
>>>> The best way for you to work if you already have an FT version that
>>>> works for you and don't want to update it for a while is to ignore the
>>>> FT version that SPM uses and pretend it's not there. Wrappers will
>>>> prevent any clashes as I explained.
>>>
>>> To add on Vladimirs comment: In practice it means that you delete the
>>> spm8/external/fieldtrip/private directory and keep the
>>> spm8/external/fieldtrip directory for the wrappers. You can do the same
>>> for
>>> fileio and forwinv (also both in fieldtrip and spm8/external).
>>> Subsequently
>>> you should ensure that the ft_xxx wrappers in spm8, respectively the
>>> fileio_xxx and the forwinv_xxx wrappers are on your matlab path, just as
>>> your normal fieldtrip version. SPM8 will call those wrappers, which will
>>> call your standard fieldtrip functions.
>>>
>>> best
>>> Robert
>>>
>>> ----------------------------------
>>> The aim of this list is to facilitate the discussion between users of the
>>> FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG
>>> and EEG analysis. See also
>>> http://listserv.surfnet.nl/archives/fieldtrip.html and
>>> http://www.ru.nl/fcdonders/fieldtrip.
>>>
>>>
>>
>> ----------------------------------
>> The aim of this list is to facilitate the discussion between users of the
>> FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG
>> and EEG analysis. See also
>> http://listserv.surfnet.nl/archives/fieldtrip.html and
>> http://www.ru.nl/fcdonders/fieldtrip.
>
> ----------------------------------
> The aim of this list is to facilitate the discussion between users of the
> FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG
> and EEG analysis. See also
> http://listserv.surfnet.nl/archives/fieldtrip.html and
> http://www.ru.nl/fcdonders/fieldtrip.
>
>

----------------------------------
The aim of this list is to facilitate the discussion between users of the FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.