Thank you, Dr Bruce.  The initial surfaces indeed had large defects (figure 1) based on version 6.0.
figure1
The following figure was obtained using version 5.3 for the same subject.
(figure 2)
It seems to be significant different between these two versions.

I am sure that I have multiple threads available. When I add the -openmp 20 flag, it showed 2000% CPU utilization.

Today when I processed the data using version 5.3 on another workstation, it showed errors as follows. 

------------------------------
 mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i orig.mgz --o orig_nu.mgz 

Linux yxk-ubuntu 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

recon-all -s try exited with ERRORS at ......
-----------------------
However, I cannot find the reason for this error.  Any help would be greatly appreciated.

Meng

Date: Thu, 14 Sep 2017 11:42:02 -0400 (EDT)
From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
Subject: Re: [Freesurfer] correcting defect
To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu>
Message-ID:
<alpine.LRH.2.20.1709141140430.19340@gate.nmr.mgh.harvard.edu>
Content-Type: text/plain; charset="utf-8"
 
Hi Meng
 
we can't diagnose either of these issues without more information and
possibly some screen shots. The topology fixer will take a very long time
if the initial surfaces have large defects. You can view these by
visualizing the ?h.inflated.nofix and ?h.orig.nofix.
 
The -openmp flag works for us. Are you sure that you have mutliple threads
available?
 
cheers
Bruce
 
On Thu, 14 Sep 2017, Meng Li wrote:
 
> Hi all,
>
> I tried to use FreeSurfer version 6.0.0 to process fifteen subjects, but half of the subjects was
> stuck at the ?Correcting Defect? step. However, when I changed to FreeSurfer version 5.3.0, the
> ?Correcting defect? step finished successfully. Is it possibility that the unsuccessful ?Correcting
> Defect? step is caused by the different versions of Freesurefer?
>
> In addition, when I added the flag -parallel -openmp 30 based on the version 6.0.0, the recon-all
> ?all runtime still need 20+ hours. It seems that the parallel processing did not reduce the
> processing time. I wonder why the parallel processing did?t save time?
>
> Any help would be greatly appreciated.
>
> Meng
>
>
>
>
> ?
>
>
>
 
------------------------------
 
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
 
End of Freesurfer Digest, Vol 163, Issue 22
*******************************************