Freesurfer

freesurfer@nmr.mgh.harvard.edu

5 participants
30076 discussions

sub-cortical parcels
by joel bruss 13 Nov '07

13 Nov '07

Hello- I'm running FreeSurfer v4.01on SUSE Linux I'm interested in viewing the sub-cortical parcels, /mri/aseg.mgz, but in the native MRI space. I see that the output of "CA Label" produces a file that is fit to the "CA Normalize" step but I can't figure out the transform that was used. Specifically, for CA Normalize, if I look under /mri/transforms, and sort by time, I have both the talairach.lta and talairach.m3z files, but neither will get me from native to norm space (or vice-versa). Is there a transform file that I'm missing or is this a process of intermediate steps to get from native to norm space? Please help! Thanks, Joel

4 8

tkregister2: target vs. movable designation
by Michael Harms 13 Nov '07

13 Nov '07

Hello, I've become confused about the direction of the transformation specified in the talairach.xfm file. It seems that if you "manually" specify the --targ and --mov volumes in conjunction with the --xfm option, that the "target" must be the talairach average to get proper alignment: e.g., tkregister2 --targ $FREESURFER_HOME/subjects/fsaverage/mri/T1.mgz --mov orig.mgz --xfm transforms/talairach.xfm --reg tmp.dat (The same targ/mov definition appears to be the case if you want to use --lta to view a .lta transform instead). However, the resulting output to the terminal for "Input registration matrix" does not match the talairach.xfm file -- is there a matrix inversion somewhere?? But, if you use the --fstal option e.g., tkregister2 --s 020819_43 --fstal then orig.mgz is now the "target" and the talairach average is now the "movable" volume, and the output to the terminal for "Input registration matrix" now exactly matches the values in the talairach.xfm file. Based on this, it seems that .xfm maps from mov to target (with orig.mgz being the target). However that doesn't seem consistent with the required mov and targ specifications with using the --xfm flag directly... thanks for clarifying, Mike H. -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

2 1

Postdoctoral and Research Assistant Positions Available
by David Salat 13 Nov '07

13 Nov '07

Postdoctoral and Research Assistant Positions Available in structural and functional neuroimaging. Massachusetts General Hospital-Athinoula A. Martinos Center for Biomedical Imaging, Charlestown MA PLEASE POST FOR ALL INTERESTED PARTIES. START DATE: Immediately Full-time postdoctoral and research assistant positions are available in structural and functional magnetic resonance imaging at the Athinoula A. Martinos Center for Biomedical Imaging in the Department of Radiology at Massachusetts General Hospital. *********************** The postdoctoral position will focus on the development of novel analysis procedures for the advanced analysis of cerebral white matter anatomy and pathology under the guidance of Dr. Bruce Fischl, and the translation of these techniques in the study of normal aging and neurological diseases including Huntington's and Alzheimer's disease. This work will involve the development of structural imaging procedures as well as the potential integration of these morphometric techniques with information from diffusion tensor imaging. This position requires a PhD in computer science or a related field. Additional skills such as knowledge of Matlab and c are required, and some familiarity with MRI acquisition and analysis is strongly preferred. ********************** The research assistant position will focus on the application of structural and functional image analysis procedures in the study of brain aging and neurological diseases including Alzheimer's and Huntington's disease. Other tasks include participant scanning, data organization, statistical analysis, and additional lab duties. This individual will be working with patients, so excellent interpersonal, organizational and communication skills are required. This position requires a Bachelor of Arts or Bachelor of Science degree, and some prior research experience is preferred. Familiarity with Linux/Unix and Matlab would be extremely useful. A two year commitment is required. This is an excellent position for a recent college graduate who wants to spend two or more years in a research setting before going on to graduate or medical school. ******************** All candidates should be willing to learn how to use our structural and functional image analysis software: http://surfer.nmr.mgh.harvard.edu Please send a resume with the names of two references, or questions to (e-mail correspondence with the subject line 'RES POSITION' preferred): David Salat Athinoula A. Martinos Center for Biomedical Imaging Massachusetts General Hospital Department of Radiology Building 149, 13th St. Mail Code: 149 (2301) Charlestown, MA 02129-2060 email: salat at nmr.mgh.harvard.edu --

1 0

longitudinal study
by Linda.E Campbell 13 Nov '07

13 Nov '07

Hi, I am about to start processing some longitudinal data and am looking for appropriate software. I know the Freesurfer allows for longitudinal designs but how appropriate is it to use for developing brains, ie in my sample the subjects are adolescents between 14-20 and they were last scanned three years ago. Since the brain and skull size changes in that time would Freesurfer be able to take that into account and what would be the best way to go about it. I would be most grateful for your advice. Thank you Linda ............................................................................ Dr. Linda Campbell, PhD NH&MRC Research fellow & Project Manager University of Newcastle Priority Research Centre Brain & Mental Health Affiliations: Hunter Medical Research Institute (HMRI) Neuroscience Institute of Schizophrenia and Allied Disorders (NISAD) Mail to: Centre for Brain & Mental Health Research Officers Quarters Complex James Fletcher Hospital Newcomen Street Newcastle NSW 2300 Australia Ph: +61-2 4924 6648 Fax: +61-2 4924 6608

2 1

Re: Freesurfer Digest, Vol 45, Issue 12
by aleontie＠meded-mail.ucsd.edu 12 Nov '07

12 Nov '07

On Mon 12 Nov 2007 11:41:12 AM PST , freesurfer-request(a)nmr.mgh.harvard.edu sent: >Send Freesurfer mailing list submissions to > freesurfer(a)nmr.mgh.harvard.edu >To subscribe or unsubscribe via the World Wide Web, visit > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurferor, via email, send a message with subject or body 'help' to > freesurfer-request(a)nmr.mgh.harvard.edu >You can reach the person managing the list at > freesurfer-owner(a)nmr.mgh.harvard.edu >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Freesurfer digest..." > > >Today's Topics: > > 1. Re: reprocessing on FS4.0 takes much longer for some scans > (Bruce Fischl) > 2. Re: reprocessing on FS4.0 takes much longer for some scans > (Pedro Paulo Oliveira Jr) > 3. RE: reprocessing on FS4.0 takes much longer for some scans > (Pedro Paulo Oliveira Jr) > 4. RE: reprocessing on FS4.0 takes much longer for some scans > (Nicolas Cherbuin) > 5. RE: reprocessing on FS4.0 takes much longer for some scans > (Bruce Fischl) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 11 Nov 2007 16:30:22 -0500 (EST) >From: Bruce Fischl fi >schl(a)nmr.mgh.harvard.edu>Subject: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for > some scans >To: Nicolas Cherbuin herbuin@an >u.edu.au>Cc: freesurfer(a)nmr.mgh.harvard.eduMessage-ID: > .4.62.0711111627310.8527(a)gate.nmr.mgh.harvard.edu>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >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 >> Freesurfer(a)nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> >> >> > > >------------------------------ > >Message: 2 >Date: Mon, 12 Nov 2007 06:23:04 -0200 >From: "Pedro Paulo Oliveira Jr" ppj@netf >ilter.com.br>Subject: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for > some scans >To: Bruce Fischl fi >schl(a)nmr.mgh.harvard.edu>Cc: freesurfer(a)nmr.mgh.harvard.edu, Nicolas Cherbuin herbuin@an >u.edu.au>Message-ID: 5@mai >l.netfilter.com.br>Content-Type: text/plain; charset=UTF-8 > >I'm sure Bruce has much more experience on the subject than me. Also >I'm not part of Martinos development team. I'll just add my personal >experience: >1) Your running times seens very high. I never saw 72 hours in my >studies. Notice that Itanium (and Itanium 2) cpu are far distinct than x86 >and x86-64, and even running correctly x86 code its performance in fpu >falls in my experience to 50%. Since FS code is not compiled to Itanium >arch I think the stated above can explain the problem. >2) Regarding memory my experience is that 1GB usually does fine if you >have swap space. >3) about 3.0.5 and 4.0.1 differences in running time my data is: 22 hrs >vs 31 hrs average. It depends on the "extended" topological fix 4.0.1 does. > >It would be nice to know your cluster configuration and a sample of >your data to give you a better advice. >best regards, > >Pedro Paulo Oliveira Jr. > >-- mens. original -- >Assunto: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for >some scansDe: Bruce Fischl fi >schl(a)nmr.mgh.harvard.edu>Data: 11/11/2007 21:42 > >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 >> Freesurfer(a)nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> >> >> >_______________________________________________ >Freesurfer mailing list >Freesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > >------------------------------ > >Message: 3 >Date: Mon, 12 Nov 2007 10:16:06 -0200 >From: "Pedro Paulo Oliveira Jr" ppj@netf >ilter.com.br>Subject: RE: [Freesurfer] reprocessing on FS4.0 takes much longer for > some scans >To: "'Bruce Fischl'" fi >schl(a)nmr.mgh.harvard.edu>, freesurfer(a)nmr.mgh.harvard.edu>, "'Nicolas Cherbuin'" herbuin@an >u.edu.au>Message-ID: >Content-Type: text/plain; charset="UTF-8" > >one correction: FS does have Itanium version. ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer-Linux-suse >-ia64-stable-pub-v4.0.1-full.tar.gz >So my guess for item (1) is check if all code running is for IA64 >architecture. >-----Original Message----- >From: freesurfer-bounces(a)nmr.mgh.harvard.edu [freesurfer-bounces(a)nmr.mgh.harvard.edu] On Behalf Of Pedro >Paulo Oliveira JrSent: segunda-feira, 12 de novembro de 2007 06:23 >To: Bruce Fischl >Cc: freesurfer(a)nmr.mgh.harvard.edu; Nicolas CherbuinSubject: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for >some scans >I'm sure Bruce has much more experience on the subject than me. Also >I'm not part of Martinos development team. I'll just add my personal >experience: >1) Your running times seens very high. I never saw 72 hours in my >studies. Notice that Itanium (and Itanium 2) cpu are far distinct than x86 >and x86-64, and even running correctly x86 code its performance in fpu >falls in my experience to 50%. Since FS code is not compiled to Itanium >arch I think the stated above can explain the problem. >2) Regarding memory my experience is that 1GB usually does fine if you >have swap space. >3) about 3.0.5 and 4.0.1 differences in running time my data is: 22 hrs >vs 31 hrs average. It depends on the "extended" topological fix 4.0.1 does. > >It would be nice to know your cluster configuration and a sample of >your data to give you a better advice. >best regards, > >Pedro Paulo Oliveira Jr. > >-- mens. original -- >Assunto: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for >some scansDe: Bruce Fischl fi >schl(a)nmr.mgh.harvard.edu>Data: 11/11/2007 21:42 > >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 >> Freesurfer(a)nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> >> >> >_______________________________________________ >Freesurfer mailing list >Freesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >_______________________________________________ >Freesurfer mailing list >Freesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >__________ NOD32 2652 (20071111) Information __________ > >This message was checked by NOD32 antivirus system. >http://www.eset.com > > > >------------------------------ > >Message: 4 >Date: Tue, 13 Nov 2007 06:08:00 +1100 >From: "Nicolas Cherbuin" herbuin@an >u.edu.au>Subject: RE: [Freesurfer] reprocessing on FS4.0 takes much longer for > some scans >To: "Bruce Fischl" fi >schl(a)nmr.mgh.harvard.edu>Cc: freesurfer(a)nmr.mgh.harvard.eduMessage-ID: > >Content-Type: text/plain; charset="Windows-1252" > >Hi Bruce, > >Thanks for your answers. I am not sure how much more ram might be >needed dependant on anatomy but my last job failed due to FS using more >than 3 Gig > PBS: job killed: per node vmem 34078384kb exceeded limit 2097152kb > >or does it suggest there is a problem with our configuration? > >Also, a related question. Since a number of jobs have failed after many >hours of processing, I have had to investigate restarting jobs to finish >processing the right hemisphere. For instance after the following log: >status file for recon-all >Thu Nov 8 23:13:39 EST 2007 >#@# MotionCor Thu Nov 8 23:13:53 EST 2007 >#@# Nu Intensity Correction Thu Nov 8 23:14:33 EST 2007 >#@# Talairach Thu Nov 8 23:15:44 EST 2007 >#@# Talairach Failure Detection Thu Nov 8 23:18:32 EST 2007 >#@# Intensity Normalization Thu Nov 8 23:18:32 EST 2007 >#@# Skull Stripping Thu Nov 8 23:25:47 EST 2007 >#@# EM Registration Fri Nov 9 00:11:07 EST 2007 >#@# CA Normalize Fri Nov 9 00:31:03 EST 2007 >#@# CA Reg Fri Nov 9 00:37:06 EST 2007 >#@# CA Reg Inv Fri Nov 9 16:56:14 EST 2007 >#@# Remove Neck Fri Nov 9 16:59:57 EST 2007 >#@# SkullLTA Fri Nov 9 17:04:39 EST 2007 >#@# SubCort Seg Fri Nov 9 17:37:12 EST 2007 >#@# CC Seg Fri Nov 9 18:57:34 EST 2007 >#@# Intensity Normalization2 Fri Nov 9 18:59:22 EST 2007 >#@# Mask BFS Fri Nov 9 19:08:32 EST 2007 >#@# WM Segmentation Fri Nov 9 19:08:45 EST 2007 >#@# Fill Fri Nov 9 19:17:29 EST 2007 >#@# Tessellate lh Fri Nov 9 19:19:57 EST 2007 >#@# Smooth1 lh Fri Nov 9 19:20:37 EST 2007 >#@# Inflation1 lh Fri Nov 9 19:20:56 EST 2007 >#@# QSphere lh Fri Nov 9 19:24:27 EST 2007 >#@# Fix Topology lh Fri Nov 9 19:58:03 EST 2007 >#@# Make Final Surf lh Sat Nov 10 03:17:04 EST 2007 >#@# Smooth2 lh Sat Nov 10 07:11:02 EST 2007 >#@# Inflation2 lh Sat Nov 10 07:11:19 EST 2007 >#@# Sphere lh Sat Nov 10 07:19:55 EST 2007 >#@# Surf Reg lh Sat Nov 10 10:29:15 EST 2007 >#@# Jacobian white lh Sat Nov 10 17:43:19 EST 2007 >#@# AvgCurv lh Sat Nov 10 17:43:29 EST 2007 >#@# Cortical Parc lh Sat Nov 10 17:43:37 EST 2007 >#@# Parcellation Stats lh Sat Nov 10 17:44:55 EST 2007 >#@# Cortical Parc 2 lh Sat Nov 10 17:45:30 EST 2007 >#@# Parcellation Stats 2 lh Sat Nov 10 17:47:12 EST 2007 >#@# Tessellate rh Sat Nov 10 17:47:58 EST 2007 >#@# Smooth1 rh Sat Nov 10 17:48:35 EST 2007 >#@# Inflation1 rh Sat Nov 10 17:48:55 EST 2007 >#@# QSphere rh Sat Nov 10 17:52:32 EST 2007 >#@# Fix Topology rh Sat Nov 10 18:26:17 EST 2007 > > >I initially thought I could restart with -autorecon3 but since this did >not work I restarted with: >recon-all -s subject -autorecon2 -hemi right > >but this (log below) restarted with a number of (very lengthy!!!) >processes that had been completed before. What is the most efficient way to >restart a process and is there a way of restarting autorecon2 and have it >automatically followed by autorecton3? >Sun Nov 11 11:29:26 EST 2007 >#@# EM Registration Sun Nov 11 11:29:26 EST 2007 >#@# CA Normalize Sun Nov 11 11:48:51 EST 2007 >#@# CA Reg Sun Nov 11 11:54:14 EST 2007 >#@# CA Reg Inv Mon Nov 12 04:21:18 EST 2007 >#@# Remove Neck Mon Nov 12 04:25:00 EST 2007 >#@# SkullLTA Mon Nov 12 04:29:31 EST 2007 >#@# SubCort Seg Mon Nov 12 05:01:49 EST 2007 >#@# CC Seg Mon Nov 12 06:21:48 EST 2007 >#@# Intensity Normalization2 Mon Nov 12 06:23:50 EST 2007 >#@# Mask BFS Mon Nov 12 06:32:52 EST 2007 >#@# WM Segmentation Mon Nov 12 06:33:05 EST 2007 >#@# Fill Mon Nov 12 06:41:56 EST 2007 >#@# Tessellate rh Mon Nov 12 06:44:23 EST 2007 >#@# Smooth1 rh Mon Nov 12 06:45:00 EST 2007 >#@# Inflation1 rh Mon Nov 12 06:45:19 EST 2007 >#@# QSphere rh Mon Nov 12 06:48:48 EST 2007 >#@# Fix Topology rh Mon Nov 12 07:22:02 EST 2007 >#@# Make Final Surf rh Mon Nov 12 15:26:46 EST 2007 >#@# Smooth2 rh Mon Nov 12 19:18:37 EST 2007 >#@# Inflation2 rh Mon Nov 12 19:18:55 EST 2007 >#@# ASeg Stats Mon Nov 12 19:27:09 EST 2007 >#@# Cortical ribbon mask rh Mon Nov 12 20:03:45 EST 2007 > >Finally, what is the best way to restart it from the last memory >exceeded failure which interupted processing towards the end of autorecon2? >Thanks > >Nic > > > >-----Original Message----- >From: Bruce Fischl [fi >schl(a)nmr.mgh.harvard.edu]Sent: Sun 11/11/2007 4:30 PM >To: Nicolas Cherbuin >Cc: freesurfer(a)nmr.mgh.harvard.eduSubject: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for >some scans >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 >> Freesurfer(a)nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> >> >> > > > > > >------------------------------ > >Message: 5 >Date: Mon, 12 Nov 2007 14:40:35 -0500 (EST) >From: Bruce Fischl fi >schl(a)nmr.mgh.harvard.edu>Subject: RE: [Freesurfer] reprocessing on FS4.0 takes much longer for > some scans >To: Nicolas Cherbuin herbuin@an >u.edu.au>Cc: freesurfer(a)nmr.mgh.harvard.eduMessage-ID: > .4.62.0711121440040.8310(a)gate.nmr.mgh.harvard.edu>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >do you know what process it was running when it failed? You could use >-autorecon2-cp and -autorecon3. Something else seems like it is wrong >though - you shouldn't need 3G of ram. > >On Tue, 13 Nov 2007, Nicolas Cherbuin >wrote: > >> Hi Bruce, >> >> Thanks for your answers. I am not sure how >much more ram might be needed dependant on anatomy but my last job failed >due to FS using more than 3 Gig> >> PBS: job killed: per node vmem 34078384kb >exceeded limit 2097152kb> >> or does it suggest there is a problem with >our configuration?> >> Also, a related question. Since a number of >jobs have failed after many hours of processing, I have had to investigate >restarting jobs to finish processing the right hemisphere. For instance >after the following log:> >> status file for recon-all >> Thu Nov 8 23:13:39 EST 2007 >> #@# MotionCor Thu Nov 8 23:13:53 EST 2007 >> #@# Nu Intensity Correction Thu Nov 8 >23:14:33 EST 2007> #@# Talairach Thu Nov 8 23:15:44 EST 2007 >> #@# Talairach Failure Detection Thu Nov 8 >23:18:32 EST 2007> #@# Intensity Normalization Thu Nov 8 >23:18:32 EST 2007> #@# Skull Stripping Thu Nov 8 23:25:47 EST >2007> #@# EM Registration Fri Nov 9 00:11:07 EST >2007> #@# CA Normalize Fri Nov 9 00:31:03 EST >2007> #@# CA Reg Fri Nov 9 00:37:06 EST 2007 >> #@# CA Reg Inv Fri Nov 9 16:56:14 EST 2007 >> #@# Remove Neck Fri Nov 9 16:59:57 EST 2007 >> #@# SkullLTA Fri Nov 9 17:04:39 EST 2007 >> #@# SubCort Seg Fri Nov 9 17:37:12 EST 2007 >> #@# CC Seg Fri Nov 9 18:57:34 EST 2007 >> #@# Intensity Normalization2 Fri Nov 9 >18:59:22 EST 2007> #@# Mask BFS Fri Nov 9 19:08:32 EST 2007 >> #@# WM Segmentation Fri Nov 9 19:08:45 EST >2007> #@# Fill Fri Nov 9 19:17:29 EST 2007 >> #@# Tessellate lh Fri Nov 9 19:19:57 EST >2007> #@# Smooth1 lh Fri Nov 9 19:20:37 EST 2007 >> #@# Inflation1 lh Fri Nov 9 19:20:56 EST >2007> #@# QSphere lh Fri Nov 9 19:24:27 EST 2007 >> #@# Fix Topology lh Fri Nov 9 19:58:03 EST >2007> #@# Make Final Surf lh Sat Nov 10 03:17:04 >EST 2007> #@# Smooth2 lh Sat Nov 10 07:11:02 EST 2007 >> #@# Inflation2 lh Sat Nov 10 07:11:19 EST >2007> #@# Sphere lh Sat Nov 10 07:19:55 EST 2007 >> #@# Surf Reg lh Sat Nov 10 10:29:15 EST 2007 >> #@# Jacobian white lh Sat Nov 10 17:43:19 >EST 2007> #@# AvgCurv lh Sat Nov 10 17:43:29 EST 2007 >> #@# Cortical Parc lh Sat Nov 10 17:43:37 EST >2007> #@# Parcellation Stats lh Sat Nov 10 >17:44:55 EST 2007> #@# Cortical Parc 2 lh Sat Nov 10 17:45:30 >EST 2007> #@# Parcellation Stats 2 lh Sat Nov 10 >17:47:12 EST 2007> #@# Tessellate rh Sat Nov 10 17:47:58 EST >2007> #@# Smooth1 rh Sat Nov 10 17:48:35 EST 2007 >> #@# Inflation1 rh Sat Nov 10 17:48:55 EST >2007> #@# QSphere rh Sat Nov 10 17:52:32 EST 2007 >> #@# Fix Topology rh Sat Nov 10 18:26:17 EST >2007> >> >> I initially thought I could restart with >-autorecon3 but since this did not work I restarted with:> >> recon-all -s subject -autorecon2 -hemi right >> >> but this (log below) restarted with a number >of (very lengthy!!!) processes that had been completed before. What is the >most efficient way to restart a process and is there a way of restarting >autorecon2 and have it automatically followed by autorecton3?> >> Sun Nov 11 11:29:26 EST 2007 >> #@# EM Registration Sun Nov 11 11:29:26 EST >2007> #@# CA Normalize Sun Nov 11 11:48:51 EST >2007> #@# CA Reg Sun Nov 11 11:54:14 EST 2007 >> #@# CA Reg Inv Mon Nov 12 04:21:18 EST 2007 >> #@# Remove Neck Mon Nov 12 04:25:00 EST 2007 >> #@# SkullLTA Mon Nov 12 04:29:31 EST 2007 >> #@# SubCort Seg Mon Nov 12 05:01:49 EST 2007 >> #@# CC Seg Mon Nov 12 06:21:48 EST 2007 >> #@# Intensity Normalization2 Mon Nov 12 >06:23:50 EST 2007> #@# Mask BFS Mon Nov 12 06:32:52 EST 2007 >> #@# WM Segmentation Mon Nov 12 06:33:05 EST >2007> #@# Fill Mon Nov 12 06:41:56 EST 2007 >> #@# Tessellate rh Mon Nov 12 06:44:23 EST >2007> #@# Smooth1 rh Mon Nov 12 06:45:00 EST 2007 >> #@# Inflation1 rh Mon Nov 12 06:45:19 EST >2007> #@# QSphere rh Mon Nov 12 06:48:48 EST 2007 >> #@# Fix Topology rh Mon Nov 12 07:22:02 EST >2007> #@# Make Final Surf rh Mon Nov 12 15:26:46 >EST 2007> #@# Smooth2 rh Mon Nov 12 19:18:37 EST 2007 >> #@# Inflation2 rh Mon Nov 12 19:18:55 EST >2007> #@# ASeg Stats Mon Nov 12 19:27:09 EST 2007 >> #@# Cortical ribbon mask rh Mon Nov 12 >20:03:45 EST 2007> >> Finally, what is the best way to restart it >from the last memory exceeded failure which interupted processing towards >the end of autorecon2?> >> Thanks >> >> Nic >> >> >> >> -----Original Message----- >> From: Bruce Fischl [fi >schl(a)nmr.mgh.harvard.edu]> Sent: Sun 11/11/2007 4:30 PM >> To: Nicolas Cherbuin >> Cc: freesurfer(a)nmr.mgh.harvard.edu> Subject: Re: [Freesurfer] reprocessing on >FS4.0 takes much longer for some scans> >> 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 >>> Freesurfer(a)nmr.mgh.harvard.edu>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer>> >>> >>> >> >> >> >> >> > > >------------------------------ > >_______________________________________________ >Freesurfer mailing list >Freesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >End of Freesurfer Digest, Vol 45, Issue 12 >****************************************** > ---- Msg sent via @Mail - http://atmail.com/

1 0

Re: Freesurfer Digest, Vol 45, Issue 12
by aleontie＠meded-mail.ucsd.edu 12 Nov '07

12 Nov '07

1 0

reprocessing on FS4.0 takes much longer for some scans
by Nicolas Cherbuin 12 Nov '07

12 Nov '07

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

3 4

Re: [Freesurfer] reprocessing on FS4.0 takes much longer for some scans
by Pedro Paulo Oliveira Jr 12 Nov '07

12 Nov '07

I'm sure Bruce has much more experience on the subject than me. Also I'm not part of Martinos development team. I'll just add my personal experience: 1) Your running times seens very high. I never saw 72 hours in my studies. Notice that Itanium (and Itanium 2) cpu are far distinct than x86 and x86-64, and even running correctly x86 code its performance in fpu falls in my experience to 50%. Since FS code is not compiled to Itanium arch I think the stated above can explain the problem. 2) Regarding memory my experience is that 1GB usually does fine if you have swap space. 3) about 3.0.5 and 4.0.1 differences in running time my data is: 22 hrs vs 31 hrs average. It depends on the "extended" topological fix 4.0.1 does. It would be nice to know your cluster configuration and a sample of your data to give you a better advice. best regards, Pedro Paulo Oliveira Jr. -- mens. original -- Assunto: Re: [Freesurfer] reprocessing on FS4.0 takes much longer for some scans De: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> Data: 11/11/2007 21:42 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 > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > _______________________________________________ Freesurfer mailing list Freesurfer(a)nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

1 1

fMRI raw data time course
by raij＠nmr.mgh.harvard.edu 09 Nov '07

09 Nov '07

Hi Doug, I am troubleshooting an fMRI measurement and would need to see the raw data time course. I have previously used sliceview-sess for this purpose, but for some reason I can no longer make it work. Well, sliceview-sess itself opens fine if I define the analysis and contrast names, but pushing "r" has no effect (should evoke raw data display), and the command line raw data request gives a vague error. I already analysed the data in both bhdr and nii formats, without improvement (a time point exclusion file was used during analysis). -v1 or -v2 makes no difference. Any suggestions would be much appreciated! Bests, Tommi ******************** on machine cuzco nmr-std-env (same problem with nmr-dev-env) cd /space/cuzco/1/users/raij/avml_fmri_mctogether/avml14_session_BRISI12/ setenv SUBJECTS_DIR /space/cognito/5/users/raij/subjects_mri/ setenv SUBJECT avml14 [cuzco:avml14_session_BRISI12] (nmr-std-env) sliceview-sess -sf sessid -df sesspar -raw 011 -motioncor -------------------------------------------------------------- sliceview-sess logfile is /autofs/space/cuzco_001/users/raij/avml_fmri_mctogether/avml14_session_BRISI12/log/sliceview-sess.log -------------------------------------------------------------- INFO: no slice specified, assuming mosaic grep: /autofs/space/cuzco_001/users/raij/avml_fmri_mctogether/avml14_session_BRISI12/session.info: No such file or directory avml14_session_BRISI12 ---------------------------------------------- /autofs/space/cuzco_001/users/raij/avml_fmri_mctogether/avml14_session_BRISI12 yakview -i /autofs/space/cuzco_001/users/raij/avml_fmri_mctogether/avml14_session_BRISI12/bold/011/fmc -r /autofs/space/cuzco_001/users/raij/avml_fmri_mctogether/avml14_session_BRISI12/bold/011/fmc -sn mos -thmin 2 -thmax 7 -title avml14_session_BRISI12 -v1 -mgh ---------------------------------------------- yakview: \$Id: yakview,v 1.11.2.1 2007/10/05 20:42:55 greve Exp $ ERROR: cannot find [cuzco:avml14_session_BRISI12] (nmr-std-env) --- Tommi Raij, M.D., Ph.D. MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging Bldg 149, 13th St Charlestown, MA 02129 U.S.A.

1 0

hardware for computing Q for Paul Raines
by Kirk, Gregory 09 Nov '07

09 Nov '07

Hi Paul, We have been plowing a lot of data with freesurfer, FSL, etc. and are thinking of moving up to a hunkier computer system, anything from 4 processor workstation to a minimal cluster. Wonder if you know a couple URL's of stuff you equipment you think is decent for a starter system G.

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer