Dear FreeSurfer experts,I found this paper about named “Reproducibility of neuroimaging analyses across operating systems” (Glatard et al., 2015). There were differences in cortical morphometry like cortical thicknes between images proscced in the same version of freesurfer with different version of Linux or glibc for Freesurfer, and according to the paper, it was caused by how different version of glibc handles small single precssion floating numbers. I have therefore some questions. Are there plans for freesurfer to use double floating numbers in steps that may be affected by numerical stability? Or can this problem be solved by using staticall linking glibc into Freesurfer? Best regards Knut Jørgen BjulandPhD candidateNTNU
On 28 August 2016 at 06:59, Knut J Bjuland knutjorgen@outlook.com wrote:
I found this paper about named “Reproducibility of neuroimaging analyses across operating systems” (Glatard et al., 2015). There were differences in cortical morphometry like cortical thicknes between images proscced in the same version of freesurfer with different version of Linux or glibc for Freesurfer, and according to the paper, it was caused by how different version of glibc handles small single precssion floating numbers. I have therefore some questions.
Are there plans for freesurfer to use double floating numbers in steps that may be affected by numerical stability? Or can this problem be solved by using staticall linking glibc into Freesurfer?
Freesurfer does use double precision numbers extensively on the CPU side (on the GPU side of things, I generally went back to singles). The issue is not one of numeric stability, and going to all-double (or all-quad) would not remove the differences - they are fundamental to how floating point arithmetic works. Put simply, for floating point numbers: a+(b+c) != (a+b)+c Any attempt to ignore this fact is going to come to grief at some point.
Freesurfer often has to do things such as "find voxels exceeding threshold" or "find most likely label for voxel." Operations like this are always going to be vulnerable to differences in the least significant bit.
Speaking from a numerical background (I have no experience in neuroscience), I would suggest embracing this behaviour rather than trying avoid it (arguably a fool's errand). Use the differences between different library versions (not just libc, but all the other numerical libraries Freesurfer uses) to provide an estimate of the confidence levels/error bounds on your Freesurfer runs. If your conclusion depends critically on using version x.y.z of a library, rather than x.y.z+1, then unless you can point to a specific bug in the library, you probably don't really have a conclusion.
Regards,
Richard
On 08/28/2016 05:57 PM, R Edgar wrote:
On 28 August 2016 at 06:59, Knut J Bjuland knutjorgen@outlook.com wrote:
I found this paper about named “Reproducibility of neuroimaging analyses across operating systems” (Glatard et al., 2015). There were differences in cortical morphometry like cortical thicknes between images proscced in the same version of freesurfer with different version of Linux or glibc for Freesurfer, and according to the paper, it was caused by how different version of glibc handles small single precssion floating numbers. I have therefore some questions.
Are there plans for freesurfer to use double floating numbers in steps that may be affected by numerical stability? Or can this problem be solved by using staticall linking glibc into Freesurfer?
Freesurfer does use double precision numbers extensively on the CPU side (on the GPU side of things, I generally went back to singles). The issue is not one of numeric stability, and going to all-double (or all-quad) would not remove the differences - they are fundamental to how floating point arithmetic works. Put simply, for floating point numbers: a+(b+c) != (a+b)+c Any attempt to ignore this fact is going to come to grief at some point.
Freesurfer often has to do things such as "find voxels exceeding threshold" or "find most likely label for voxel." Operations like this are always going to be vulnerable to differences in the least significant bit.
Speaking from a numerical background (I have no experience in neuroscience), I would suggest embracing this behaviour rather than trying avoid it (arguably a fool's errand). Use the differences between different library versions (not just libc, but all the other numerical libraries Freesurfer uses) to provide an estimate of the confidence levels/error bounds on your Freesurfer runs. If your conclusion depends critically on using version x.y.z of a library, rather than x.y.z+1, then unless you can point to a specific bug in the library, you probably don't really have a conclusion.
Regards,
Richard
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.
Hi
Thanksfortheanswer.
Isitpossibletouseascripttoextractinformation aboutwhichlibrarythatisusedforeachrecons? Orarethereanyothermeanstogetthisinformation?
How do you? "Use the differences between different library versions (not just libc, but all the other
numerical libraries Freesurfer uses) to provide an estimate of the confidence levels/error bounds on your Freesurfer runs"
Regards
Knut Jørgen
On 29 August 2016 at 02:24, Knut J Bjuland knutjorgen@outlook.com wrote:
Is it possible to use a script to extract information about which library that is used for each recons? Or are there any other means to get this information?
I'm not sure about that. At least some of the info is recorded as part of the official freesurfer build, but I don't know off hand if all the library versions are recorded.
How do you? "Use the differences between different library versions (not just libc, but all the other numerical libraries Freesurfer uses) to provide an estimate of the confidence levels/error bounds on your Freesurfer runs"
Run the same analysis of your subjects with builds linked against different library versions (in a manner similar to that in the paper you mention). Check to see that those results still support your preliminary conclusion.
Regards,
Richard
freesurfer@nmr.mgh.harvard.edu
-
Knut J Bjuland -
R Edgar