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 *******************************************
Hi Meng
something went wrong with the segmentation in V6 I expect. If you upload the subject we will take a look
cheers Bruce
On Sat, 16 Sep 2017, limengsecret@126.com wrote:
Thank you, Dr Bruce. The initial surfaces indeed had large defects (figure 1) based on version 6.0. [IMAGE] figure1 The following figure was obtained using version 5.3 for the same subject. [IMAGE](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
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
limengsecret＠126.com