Skip to content

Conversation

@Lestropie
Copy link
Member

Collaborator encountered the situation that when tcksift2 is run with -nthreads 0, it does nothing. It turns out that I buggered up the calculation of fixel track counts & track densities: the multi-threaded class destructor would mutex and increment the track density of the shared class, but this was erroneously interpreted as being the track density (i.e. intersection length) of a single streamline. As a result, the model thought that the number of streamlines in each fixel was equal to the number of threads. This is only consequential at the commencement of iterations, where any fixel with only 1 solitary streamline is excluded from the optimisation. Because of the bug, this meant that if only 1 thread was used to map streamlines to fixels, the model would exclude all fixels from the optimisation.

To demonstrate, the tcksift2 test added here fails on master.

The mechanism implemented for omitting exclusion of fixels traversed by only one streamline was erroneously being incremented based on the number of threads used to calculate the track density in each fixel. This resulted in this mechanism having no effect when executed with multi-threading, and an inability for the command to do anything if executed without multi-threading as all fixels would be excluded.
@Lestropie Lestropie added the bug label Mar 10, 2022
@Lestropie Lestropie added this to the 3.0.4 milestone Mar 10, 2022
@Lestropie Lestropie requested a review from jdtournier March 10, 2022 00:02
@Lestropie Lestropie self-assigned this Mar 10, 2022
@Lestropie Lestropie requested review from a team and removed request for jdtournier March 10, 2022 03:20
Copy link
Member

@jdtournier jdtournier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, not sure I get the subtleties here. But everything seems sensible, and as long as the tests check out, it's all good as far as I'm concerned.

Just one quick question: does this not impact on the validity of previous results, even when running with more than one thread? It seems like quite a fundamental change if the quantity being updated in the destructor is not the right one...

@Lestropie
Copy link
Member Author

It means that previously, fixels to which only one streamline was assigned would nevertheless still be included in the optimisation, despite my intention for them not to be. So technically yes, it may change outcomes slightly, but I nevertheless think it's a patch fix.

@Lestropie Lestropie merged commit ed95584 into master Mar 11, 2022
@Lestropie Lestropie deleted the tcksift2_nthreads0_fix branch March 11, 2022 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants