Duke-UNC Brain Imaging and Analysis Center
BIAC Forums | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Support Forums
 Cluster Support
 insufficient RAM? "dc: stack empty"

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
dvsmith 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]----
10   L A T E S T    R E P L I E S    (Newest First)
dvsmith 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.
francis.favorini 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.
dvsmith 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.
syam.gadde 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 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.)
petty 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

dvsmith 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).

dvsmith 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



syam.gadde 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"
petty 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

BIAC Forums © 2000-2010 Brain Imaging and Analysis Center Go To Top Of Page
This page was generated in 0.28 seconds. Snitz Forums 2000