Hi Matthew

Probtrackx uses a standard C function for generating random numbers, like 
rand(). Unfortunately, I think that the C/C++ standard does not guarantee that 
running rand() on different machines will give you the same random sequence, so 
there is no way to be sure that this will happen. I would say as a minimum you 
need the different machines to have the same operating system, same bit 
representation and same compilers.

However, you can still test reproducibility of various options as you would do 
with any stochastic result. It is just that your “perfect” reproducibility 
measure won’t be 1, but it will have a lower value corresponding to the 
run-rerun reproducibility. I.e. if you run your baseline scripts a few (at 
least two) times using the same data/settings that will give you a 
reproducibility measure that you can use as an "upper bound”. And you should 
obviously expect that this run-rerun reproducibility within subject should be 
higher than similarity of connectomes between subjects.

Hope this helps
Stam



On 25 Sep 2015, at 11:01, Matthew George Liptrot 
<[email protected]<mailto:[email protected]>> wrote:

Hiya,

I'm testing the generation of connectivity matrices from the HCP diffusion data 
(matrix3 format), using code based upon the HCP tractography pipeline.

When I run the tractography on different machines, I get different connectivity 
matrices. The binaries are identical, as is the bedpostx data.
I’m assuming that the difference comes from the probtrackx2 and its use of the 
‘rseed’ option (which is also set to be the same on both machines).
I guess that the ‘rseed’ option, besides being just a tag/label for each 
repeated run of probtrackx2, is also used to seed a pseudo-random number 
generator?

If so, does that mean that there is not any way for us to replicate the 
probtrackx2 results on different machines?
This is important for us as we are analysing and using the replication of 
connectivity matrices between (and within) subjects.
And so it might become an issue when the fsl_sub is distributing these 
(repeated, within-subject runs) of probtrackx across multiple nodes of a CPU 
cluster, meaning we will never be able to replicate any experiment unless we 
somehow keep track of which probtrackx2 job is executed on which node…

Many thanks!

M@
--
Matthew George Liptrot

<http://about.me/matthewliptrot>
Department of Computer Science
University of Copenhagen
&
Section for Cognitive Systems
Department of Applied Mathematics and Computer Science
Technical University of Denmark

http://about.me/matthewliptrot


_______________________________________________
HCP-Users mailing list
[email protected]<mailto:[email protected]>
http://lists.humanconnectome.org/mailman/listinfo/hcp-users


_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Reply via email to