Ha, that’s funny. The dimensions seem perfectly fine to me …
Juan Eugenio Iglesias ERC Senior Research Fellow Translational Imaging Group University College London http://www.jeiglesias.com http://cmictig.cs.ucl.ac.uk/
On 30 Mar 2017, at 09:16, Ferdi van de Kamp <ferdivdkamp@gmail.commailto:ferdivdkamp@gmail.com> wrote:
Hi Eugenio,
I've been trying figure out what is going on and part of the problem seems to be a buggy scheduler, which cannot be remedied at the moment. E.g. 64G maxvmem is reached in one subject within 12 seconds (when running a batch of over 100 participants). Running it again later (in a very small batch of 3 subjects) results in a succesful processing at maxvmem of 19G..
The scans we use have these dimensions, are they in any way problematic?
data_type INT16 dim1 256 dim2 256 dim3 140 dim4 1 datatype 4 pixdim1 0.8750000000 pixdim2 0.8750000000 pixdim3 1.2000000477 pixdim4 0.0000000000 cal_max 0.0000 cal_min 0.0000 file_type NIFTI-1+
Cheers,
Ferdi _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto: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.