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.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.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.