Hi Nicolas,
1. No, sorry, the amount of RAM is sometimes dependent on the
individual anatomy, and in any case can't be predefine.
2. Not sure about the itaniums. We have no real experience. 72 hours does
sound pretty long. That's I think about what it used to take on our old
athlons. Can you extend the time limit?
As for the random stopping of recon-all, we have seen that sometimes as
well, and are trying to track it down. It seems pretty mysterious, as a
binary will exit with a nonzero exit code according to the shell even
though the last printf in the code has been executed and the next statement
is an exit(0).
Bruce
On
Mon, 12 Nov 2007, Nicolas Cherbuin wrote:
Hi,
At the beginning of the year I processed 400 scans on a linux cluster. It had a
reported ram limit of 1 Gig but it could cope with the slight excess of FS3 and
a processing time limit of 48 hours (which was fine for 99% of the scans). Most
scans went through autorecon-all without problem.
I am now trying to reprocess the scans with the new version but I am running
into a number of problems. On the same linux cluser processing the same scans,
some scans (~30%) run without problem. The rest either fail because they exceed
the memory limit or because they take much more than 48 hours (the jobs are
being killed and the logs report only the left and sometimes part of the right
hemisphere being processed).
Since the documentation makes clear that FS works best with 2 Gig of ram, I
have switched to an Itinium cluster with 2 Gig ram limit and 48 hours
processing time limit. When I compare the logs of the same scans processed on
both systems the Itinium cluster seems to take longer and although I am still
running tests it appears that for at least some scans autoreconall might take
70+ hours.
Here are my questions:
1. On the linux cluster can I tell freesurfer not to exceed a certain ram
allocation? and if yes how?
2. Do the problems I have on the Itinium cluster suggest that FS is badly
configured on this system? and if yes where should we look? (I don't have
access to this system's configuration and I have to feedback to the system
managers to fix eventual problems.)
Thank you very much for your help and for sharing these great tools with us.
Nic
_______________________________________________
Freesurfer mailing list
[email protected]
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
[email protected]
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
