| Author |
 Topic  |
|
|
dvsmith
Advanced Member
USA
218 Posts |
 Posted - Jun 17 2010 : 11:03:57 PM
|
I'm getting a random error in FSL that could be related to a memory issue, though I really have no idea what's going on, and I realize it might just be an FSL bug. I'm running feat_gm_prepare because I want to utilize the voxelwise covariates. It seems there is a very specific -- and seemingly simple -- part of their script that fails (i.e., "match_smoothing") every time. I was able to do this on the old cluster without any problem, so that's another reason I don't it's FSL... Any ideas?
MAINDIR=${EXPERIMENT}/Analysis/FSL
FILENAME=${MAINDIR}/34712/Active/PreStatsOnly/Smooth_6mm/run1.feat
func_smoothing=`grep "fmri(smooth)" $FILENAME/design.fsf | tail -n 1 | awk '{print $3}'`
standard_space_resolution=`${FSLDIR}/bin/fslval $FILENAME/reg/standard pixdim1`
struc_smoothing=`${FSLDIR}/bin/match_smoothing $FILENAME/example_func $func_smoothing $1/reg/highres $standard_space_resolution`
echo $struc_smoothing
So, that one little piece of code, which has nothing to do with the segmentation, keeps throwing this error when I run feat_gm_prepare.
----JOB [debug.sh.350068] START [Thu Jun 17 22:41:12 EDT 2010] on HOST [node48]----
dc: dc: dc: stack empty
dc: dc: stack empty
dc: register 'e' (0145) is empty
dc: dc: dc: stack empty
dc: dc: dc: stack empty
dc: stack empty
dc: stack empty
dc: dc: stack empty
dc: dc: stack empty
dc: register 'e' (0145) is empty
dc: dc: dc: stack empty
dc: dc: dc: stack empty
dc: stack empty
dc: stack empty
dc: dc: stack empty
dc: dc: stack empty
dc: register 'e' (0145) is empty
dc: dc: dc: stack empty
dc: dc: dc: stack empty
dc: stack empty
dc: stack empty
** ERROR (nifti_image_read): failed to find header file for '/tmp/fsl_z6tbAb_new'
** ERROR: nifti_image_open(/tmp/fsl_z6tbAb_new): bad header info
Error: failed to open file /tmp/fsl_z6tbAb_new
ERROR: Could not open image /tmp/fsl_z6tbAb_new
Image Exception : #22 :: Failed to read volume /tmp/fsl_z6tbAb_new
terminate called after throwing an instance of 'RBD_COMMON::BaseException'
/usr/local/packages/fsl-4.1.5/bin/match_smoothing: line 71: 27431 Aborted ${FSLDIR}/bin/flirt -in ${IN} -ref ${IN}_new -out ${IN}_new -applyxfm
** ERROR (nifti_image_read): failed to find header file for '/tmp/fsl_z6tbAb_new'
** ERROR: nifti_image_open(/tmp/fsl_z6tbAb_new): bad header info
Error: failed to open file /tmp/fsl_z6tbAb_new
Cannot open volume /tmp/fsl_z6tbAb_new for reading!
** ERROR (nifti_image_read): failed to find header file for '/tmp/fsl_z6tbAb_new_mask'
** ERROR: nifti_image_open(/tmp/fsl_z6tbAb_new_mask): bad header info
Error: failed to open file /tmp/fsl_z6tbAb_new_mask
ERROR: Could not open image /tmp/fsl_z6tbAb_new_mask
Image Exception : #22 :: Failed to read volume /tmp/fsl_z6tbAb_new_mask
terminate called after throwing an instance of 'RBD_COMMON::BaseException'
** ERROR (nifti_image_read): failed to find header file for '/reg/highres'
** ERROR: nifti_image_open(/reg/highres): bad header info
Error: failed to open file /reg/highres
Cannot open volume /reg/highres for reading!
dc: stack empty
dc: stack empty
dc: stack empty
dc: stack empty
dc: stack empty
Usage: fslcreatehd <xsize> <ysize> <zsize> <tsize> <xvoxsize> <yvoxsize> <zvoxsize> <tr> <xorigin> <yorigin> <zorigin> <datatype> <headername> fslcreatehd <nifti_xml_file> <headername> Datatype values: 2=char, 4=short, 8=int, 16=float, 64=double In the second form, an XML-ish form of nifti header is read (as output by fslhd -x) Note that stdin is used if '-' is used in place of a filename .15
----JOB [debug.sh.350068] STOP [Thu Jun 17 22:41:25 EDT 2010]----
|
|
|
petty
BIAC Staff
USA
453 Posts |
Posted - Jun 18 2010 : 10:19:57 AM
|
Does the directory in the FILENAME variable need to exist? I tried to run this through the command line, and it all failed because that path isn't valid.
Also the "stack empty" error is most likely because whatever they are expecting to be in memory is not there ... maybe there was a failure at an earlier point and the inputs to the next function aren't present |
 |
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Jun 18 2010 : 10:37:04 AM
|
I get very similar results if I run match_smoothing with non-numeric arguments in place of the $func_smoothing and $standard_space_resolution variables in your code above. The fact that dc is complaining about "register e" implies something is wrong in the numbers that are being sent to it. I would first make sure that fmri(smooth) is defined in your design.fsf file, and that the command:
${FSLDIR}/bin/fslval $FILENAME/reg/standard pixdim1
returns an appropriate value. You could also just do this in your script before running match_smoothing to see what it prints out:
echo "func_smoothing=$func_smoothing"
echo "standard_space_resolution=$standard_space_resolution"
|
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Jun 18 2010 : 10:42:24 AM
|
I forgot to mention that I'm doing this on SocReward.03 (Fatt). You should be able to do the same thing with any first level feat directories that also do preprocessing (and include an anatomical as part of registration).
This is the earliest stage in $FSLDIR/bin/feat_gm_prepare. You can take a look at the code in that script and see that the first thing it tries to do is match the smoothing for the functional and anatomical images. I tried to run this chunk independently of feat_gm_prepare, so that's the code I posted earlier -- and it failed in exactly the same way. I just took a look at $FSLDIR/bin/match_smoothing, and I think it might be failing pretty early in the process. It doesn't seem to get to the point of creating tmp images, but everything before that point doesn't seem memory-intensive, so I have no idea why it's crashing.
Thanks,
David
|
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Jun 18 2010 : 10:55:33 AM
|
Hi Syam,
I just took a look at that, and the values are correct:
func_smoothing=6
standard_space_resolution=2.0000000000
Could it be crashing because of the decimal point in 2.000000? I know BASH doesn't like decimal points, and I think it treats everything with a decimal as a string, but I'm not sure if any of the calls in match_smoothing would have a problem with a decimal point (especially if this is default format for the header values).
|
|
|
|
petty
BIAC Staff
USA
453 Posts |
Posted - Jun 18 2010 : 11:03:44 AM
|
Your design.fsf has a carriage return in it, which was really screwing up your struct_smoothing variable
[petty@node56 FSL]$ grep "fmri(smooth)" $FILENAME/design.fsf | tail -n 1 | awk '{print $3}' | od -a
0000000 6 cr nl
0000003
[petty@node56 FSL]$ echo ${FSLDIR}/bin/match_smoothing $FILENAME/example_func $func_smoothing $1/reg/highres $standard_space_resolution
/reg/highres 2.00000000001.5/bin/match_smoothing /home/petty/net/fatt/data/Huettel/SocReward.03/Analysis/FSL/34712/Active/PreStatsOnly/Smooth_6mm/run1.feat/example_func 6
When i copied the design.fsf elsewhere and ran dos2unix, the carriage returns were removed and the struct_smoothing variable looked normal again. I couldn't run the command because i didn't know what your $1 was, but try the dos2unix and rerun the script.
this was after dos2unix ... notice there is no "cr"
[petty@node56 FSL]$ grep "fmri(smooth)" design.fsf | tail -n 1 | awk '{print $3}' | od -a
0000000 6 nl
0000002
|
Edited by - petty on Jun 18 2010 11:04:52 AM |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Jun 18 2010 : 11:25:44 AM
|
Ah... That fixed it... Thanks Chris! I noticed some other folks have been having similar issues with random characters getting into scripts/files recently (http://www.biac.duke.edu/forums/topic.asp?TOPIC_ID=1431) -- any idea what might be causing that?
(BTW, the $1 was actually supposed to be $FILENAME -- I forgot to edit that part of feat_gm_prepare.) |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Jun 18 2010 : 11:32:04 AM
|
If you edited an .fsf file or shell script in, say, Notepad on Windows, it will try to be very helpful and add carriage returns. There may be other reasons the carriage return gets in there, but that is by far the most frequent cause.
|
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Jun 18 2010 : 11:38:00 AM
|
| Yeah, I knew that would be a problem. I don't really use Windows at all anymore (just my Mac, the Cluster, and occasionally an Ubuntu Linux system I have in Scott's lab). Moreover, I never really open the design.fsf anyway, so I'm a little confused about how these characters are appearing. |
|
|
|
francis.favorini
Forum Admin
USA
618 Posts |
Posted - Jun 18 2010 : 2:15:28 PM
|
| You may want to check your SSH client to make sure it isn't set to include CR with LF. Could be a problem if you edit files. |
IT Director, Brain Imaging and Analysis Center |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Jun 19 2010 : 12:05:23 AM
|
Good suggestion, thanks... I couldn't find anything to suggest that, but I could be overlooking something. I think OS X uses LF exclusively -- but I could easily be wrong.
The odd thing to keep mind is this: to the best of my knowledge, the design.fsf are never touched by anything other than the Hugin. |
|
|
| |
Topic |
|
insufficient RAM? "dc: stack empty"
