Adjust number of threads for SLR in Recobundles #1745
Conversation
|
Hello @frheault, Thank you for updating !
Comment last updated on February 23, 2019 at 20:58 Hours UTC |
|
Looks great. Would you mind adding a test that exercises this functionality? Thanks! |
Codecov Report
@@ Coverage Diff @@
## master #1745 +/- ##
=========================================
Coverage ? 84.27%
=========================================
Files ? 115
Lines ? 13683
Branches ? 2158
=========================================
Hits ? 11531
Misses ? 1649
Partials ? 503
|
Garyfallidis
changed the title
I think I made one that make senses, it run RB twice (one single-thread and the other multi-thread) and the output is expect to be almost equal. The optimizer does not give identical results due to the multi-threading, but the streamline are almost equal (to 4 decimals) |
|
|
||
| # check if the bundle is recognized correctly | ||
| # multi-threading prevent an exact match | ||
| for row in D: |
There was a problem hiding this comment.
What type is D at this point? It's not an array?
Do you understand why multi-threading prevents an exact match? Is there any additional randomness introduced within the algorithm, beyond the control you have via rng?
There was a problem hiding this comment.
Hey @frheault : I'd love to be able to merge this in. Any thoughts on these questions?
There was a problem hiding this comment.
(Sorry I misclicked the last time and the comment was pending, my mistake)
D is an array, I used the same test "format" as every other recobundle test. I didn't want to diverge too much from the existing code. That's why I used this verification style.
The randomness is introduced from the optimizer ('L_BFGS_B' or 'Powell') from dipy.core.optimize import Optimizer which ultimately call scipy.optimize import fmin_l_bfgs_b, fmin_powell does not accept fixed initialization or seed.
rng only controls the shuffle and clustering of QBx, so the input to the optimizer is identical. The optimizer reach the same local minima, however the slight difference comes from numerical error due to different initialization for each thread.
There was a problem hiding this comment.
Gotcha. That all makes sense to me. The fact that scipy.optimize has randomization in it is very unfortunate, but out of our control here.
This all looks fine to me. I'm +1 for the merge here.
Does anyone else want to take a look? If so, please do so in the next couple of days. I'll merge this mid next week, if no one complains before that.
There was a problem hiding this comment.
LGTM. I can merge if you want, or you can go ahead.
Thanks @frheault
|
Yup. Do it!
…On Fri, Mar 1, 2019 at 10:33 AM Jean-Christophe Houde < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In dipy/segment/tests/test_refine_rb.py
<#1745 (comment)>:
> + slr=True,
+ slr_num_threads=None)
+
+ rb_single = RecoBundles(f, greater_than=0, clust_thr=10,
+ rng=np.random.RandomState(42))
+ rec_trans_single_thread, _ = rb_single.recognize(model_bundle=f2,
+ model_clust_thr=5.,
+ reduction_thr=10,
+ slr=True,
+ slr_num_threads=1)
+
+ D = bundles_distances_mam(rec_trans_multi_threads, rec_trans_single_thread)
+
+ # check if the bundle is recognized correctly
+ # multi-threading prevent an exact match
+ for row in D:
LGTM. I can merge if you want, or you can go ahead.
Thanks @frheault <https://github.com/frheault>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1745 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHPNndlYxB7oD3cJneKthOjCx--v7Eqks5vSUg_gaJpZM4bIZ3N>
.
|
Pass down the num_thread parameters and fix verbose
No change in behaviour, the default is still all CPU available
Without this option, using recobundles in a pipeline is sub-optimal