Hi Daniel,
On Jun 5, 2013, at 19:22 , Daniel LaFreniere wrote:
Dear Freesurfer Experts,
I'm currently in the middle of processing high resolution MRI through the standard FS pipeline. I've recently read a very interesting article and wanted to attempt a high resolution protocol for a bit of a side project - we initially obtained an iso resolution of 0.375mm so I might as well try and make use of it and learn something along the way!
However, I'm starting to run into issues straight from the get-go during -autorecon1. The flag I use is as follows:
recon-all -autorecon1 -mprage -hires -nuiterations 10 -subjid fom04_hires2
Often I use -washu_mprage (dark GM) and -nuiterations closer to 50 since it doesn't seem to hurt anything (the hires protocol takes much longer so I've reduced to 10-20).
After -nuiterations finishes running, I suddenly get the following error:
Writing to ./tmp.mri_nu_correct.mni.902/output.mean.dat mris_calc -o ./tmp.mri_nu_correct.mni.902/nu20.mnc ./tmp.mri_nu_correct.mni.902/nu20.mnc mul 1.33669825436408977556 mris_calc(5163) malloc: *** mmap(size=864002048) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug mris_calc: virtual memory exhausted. Cannot allocate memory Darwin dhcp-10-23-184-237.capitalhealth.ca 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
recon-all -s fom04_hires2 exited with ERRORS at Wed Jun 5 10:42:36 MDT 2013
For reference, I've added the more detailed recon-all log as well. I'm running a Macbook Pro, OS X 10.8 with 8GB of RAM/2.9 GHz with FS version 5.1.0. I've also been keeping my eye on the Activity Monitor and continuously purge inactive memory as freesurfer runs. I've even had the program crash when I'm sitting at 5 GB of unused memory with a VM size readout of about 420 GB. I can't seem to figure out what's happening but have a feeling that I just need a much more powerful computer to process the 0.375mm voxels. Any help, suggestions, or insight would be greatly appreciated.
Well the 5.1 macosx version of free surfer is compiled as 32bit binary so the theoretical maximum for each of its processes is 4GB with 3 or 2 GB more likely (I really do not know how macosx has implemented the user/kernel me,pry space split for 32 bit binaries, google might be of help). So I assume mris_calc is trying to allocate more memory than 32bit binaries can and gets his allocation denied. The 5GB unused memory would point at a 32bit user addressable range of around 2 GB (assuming that the system will have other things running). My recommendation would be to switch to 5.3 as that is comiled as 64bit binary. To test this hypothesis use: file `which mris_calc` on my 64bit macosx 10.7.5 lion system with free surfer 5.3 I get /opt/freesurfer-Darwin-lion-stable-pub-v5.3.0/bin/mris_calc: Mach-O 64-bit executable x86_64 while for old free surfer 4.5 I get: file ./mris_calc ./mris_calc: Mach-O executable i386
so that will allow you to test the hypothesis of fitness.
In general I agree with Matt that free surfer seems to prefer to do most of its processing on 1mm isotropic volumes.
Best Sebastian
Thank you very much for your time,
Dan
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.