labelsgmfix gets stuck


I am running the labelsgmfix command as follows:

labelsgmfix -force -nthreads ${cores} \
			Schaefer2018_400Parcels_7Networks.nii.gz \
			${SBJ}_T1_iso_reoriented.nii.gz \
	                Schaefer2018_400Parcels_7Networks_order_LUT.txt \
			Schaefer2018_400Parcels_7Networks_fixSGM.nii.gz \
			-premasked -sgm_amyg_hipp

The T1 ($SBJ_T1_iso_reoriented.nii.gz) comes from recon-all output ‘T1.mgz’ which is reoriented using fsl2reorient2std.

I have run this process for over 300 T1s and it seems to works fine for most but for some subjects, labelsgmfix command just gets stuck. It does not produce an error but just hangs up. I have tried using cores up to 20 and left it running for as long as a day, but it does not move forward.

I was wondering if you have seen this problem before? I’d really appreciate if you could help with this!


Hi Kausar,

A complete hang of labelsgmfix occurs in the specific instance where FSL’s run_first_all detects and utilises SGE, but the segmentation of one or more structures fails. There should be a terminal message produced at the point at which FIRST is run. The issue is that when using SGE, the run_first_all script terminates and indicates success before the segmentations actually occur; so the MRtrix3 wrapper script waits until all of the segmentations are completed and the output files appear; but if one of those segmentations fails for any reason, then the script is left waiting forever for an output file that will never appear.

You should be able to navigate into the scratch directory left in place by one of the hanging executions and find the relevant FSL FIRST error logs. Hopefully Googling whatever is provided in those will get you closer to a solution. I’ve done what I think I can in terms of coaxing that script to succeed, but it’s somewhat out of my control and I don’t have experience with passing a wide array of data through it to have learned what works and what does not.