Hi,
if you switch to 5.1 you need to also redo the 20 bases! I would simply rerun everything with 5.1 depending on availability of a cluster. If processing capacities are sparse, just run all bases and long with 5.1 and keep cross sectionals runs in 5.0.
Best, Martin
On Aug 11, 2011, at 10:35 PM, Jeff Sadino wrote:
Thank you all for your help. Nick, I installed fs 5.1.0, and it is running correctly now. This brings up another question though. We have about 200 subjects (600 scans) we are doing reconstruction on. We are done with the cross-sectional, and have completed 20 of the base templates, all in fs 5.0.0. My fs 5.0 installation is running mri_robust_register 1.31.2.1 and mri_robust_template 1.18.2.3, both dated 7/22/10. Should I update those binaries with the ones from fs 5.1.0, or would it be better to just do the rest of the processing (180 templates and 600 long runs) in fs 5.1.0?
Thank You! Jeff Sadino
On Wed, Aug 10, 2011 at 10:27 AM, Nick Schmansky nicks@nmr.mgh.harvard.edu wrote: stable 5.1 contains the fix, which is the addition of -w to the grep on line 5428. that particular fix works for the example names given (100001 as the basename, 100001_S0 and 100001_S1 in the base-tps file).
can someone give me the basename and base-tps contents so that i can replicate the problem?
n.
On Wed, 2011-08-10 at 14:45 -0400, Martin Reuter wrote:
Hi Nick, can you look into this? I think we fixed this bug in 5.0 or is it something different? Is it still not fixed in 5.1?
Thanks, Martin
On Wed, 2011-08-10 at 11:19 -0700, Irwin, William wrote:
Hi-
Note, this bug still exists in 5.1. Below is my exchange with Martin and Nick a several months ago.
-Wil
|-----Original Message----- |From: Nick Schmansky [mailto:nicks@nmr.mgh.harvard.edu] |Sent: Wednesday, May 25, 2011 3:52 PM |To: Irwin, William; Martin Reuter |Subject: RE: 5.1.0 Longitudial syntax question | |Martin, | |attached is his log. it seems like it will fail if the basename |partially matches a timepoint name. | | | |Wil, there are two possible workarounds: | |1) edit line 5421 of recon-all to change: |if ( ! $status) then | |to | |if ( 0 ) then | | |so that this block is never run | |or | |2) change the name of the basename so that its not a sub-match, for |instance change to xxxxxxx_base | | |we'll have to figure out how this happened. | |n.
|-----Original Message----- |From: Martin Reuter [mailto:mreuter@nmr.mgh.harvard.edu] |Sent: Wednesday, August 10, 2011 10:10 AM |To: Jeff Sadino |Cc: freesurfer@nmr.mgh.harvard.edu |Subject: Re: [Freesurfer] Longitudinal Subject/Base name errors | |Hi Jeff, | |this was a known bug in 5.0 and there are fixes on the web (release notes), |just download the recon all from there (and did you grab the robust template |binary)?. | |http://surfer.nmr.mgh.harvard.edu/fswiki/ReleaseNotes | |Best, Martin | |On Mon, 2011-08-08 at 17:43 -1000, Jeff Sadino wrote: |> Hello Experts, |> |> |> I am using fs 5.0.0. My naming convention is similar to 100001_S01 |> and 100001_S02 for subject, and then 100001 for the base. Now when I |> process the runs longitudinally, I get: ERROR: longitudinal base ID |> cannot be the same as a timepoint. I believe this is because of line |> 4845 in recon-all: grep $longbaseid |> ${longbasedir}/${BaseSubjsListFname} >& /dev/null. I can just as |> easily cut out this part of the code, or I could manipulate the |> base-tps file, or rename the base folder. But I do not know if there |> are other spots in the code that rely on the original naming |> conventions. Can anyone recommend one approach over the other? |> |> |> Thank you very much, |> Jeff Sadino |> _______________________________________________ |> 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.