Finally I've decided to move to fsl 4.1.1 from 4.0... We have quite a few analyses done with previous versions and usual workflow is to have pregenerated (per subject) design.fsf files and feed them into command line 'feat' tool (instead of going through graphical Feat). Unfortunately first level analysis using 4.1.1's feat (v 5.98) ran on design.fsf from previous version (FEAT 5.63) failed. Excerpts from report_log.html: ,--- | /usr/share/fsl/bin/feat_model design | Can't find key fmri(evs_vox) `--- which leads to absent design.mat, thus film_gls fails later on with ,--- | /usr/share/fsl/bin/film_gls -rn stats -sa -ms 5 filtered_func_data design.mat 1000.0 | Log directory is: stats | | | An exception has been thrown | Unable to open design.mat | Error: FILM did not complete - it probably ran out of memory `--- Adding ,--- | set fmri(evs_vox) 0 `--- into design.fsf seems to help at this level, but I am not sure if it is not the same cause (some additional options introduced in feat from FSL 4.1.1) which leads to the failed 2nd level analysis which will be reported in the separate bugreport. I think that assuming defaults for freshly introduced options in design.fsf is an important issue since it forbids bulk analysis of the data from previous versions of FSL (even of the same major release FSL 4)
When trying to load an fsf file (design file) in the feat gui (one that
ran successfully under 4.0) I got the following error output:
can't read "fmri(confoun": no such variable
can't read "fmri(confoun": no such variable
while executing
"set fmri(confoun"
(file
"/raid/research/autism_mri/2nd_level_analyses/eo-ao_face_design.fsf"
line 329)
invoked from within
"source ${filename}"
(procedure "feat5:load" line 25)
invoked from within
"feat5:load .r 1
/raid/research/autism_mri/2nd_level_analyses/eo-ao_face_design.fsf"
("eval" body line 1)
invoked from within
"eval "$command $outputfile1" "
(procedure "feat_file:invoke" line 29)
invoked from within
"feat_file:invoke .wdialog1 a a a :: {feat5:load .r 1}"
invoked from within
".wdialog1.f4.but_ok invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tk::ButtonUp" line 22)
invoked from within
"tk::ButtonUp .wdialog1.f4.but_ok"
(command bound to event)
Hi, Thanks for reporting this bugs. However, I think I cannot help in this case. FSL 4.1 is a new major release and the upstream authors do not intend the majors to be backward compatible -- at least the common advice on the mailing list is to not do further processing with a later release. Of course I could try to provide a fail-safe layer in the Debian package, but recent history told me to not divert too much from the upstream sources. Sorry, Michael
Hi, Thanks for reporting this bugs. However, I think I cannot help in this case. FSL 4.1 is a new major release and the upstream authors do not intend the majors to be backward compatible -- at least the common advice on the mailing list is to not do further processing with a later release. Of course I could try to provide a fail-safe layer in the Debian package, but recent history told me to not divert too much from the upstream sources. Sorry, Michael
Dear submitter, as the package fsl has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1009276 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)