[RTM] ENH: Merge T1w images to unbiased template if N < 3 or --longitudinal is passed

[effigies]

Not running against CircleCI at this point because we'll need to test outside of CI against datasets with multiple T1w images before we merge this. This is a placeholder PR until then.

I'd also like to go ahead and use mri_robust_register to align any T2w images (see #474).

Note that this could break alignment between result images from previous FMRIPREP versions. Should probably be put into release notes.

Closes #310

[effigies]

This adds serious run time to the t1_merge node for ds031, which merges 9 T1w images (testing after rebasing on top of #601). We could make it an option (--longitudinal?) with a note that runtime may be increased.

Also, I think we can use OpenMP, so I'll give that a shot.

[chrisgorgo]

how serious?

[effigies]

It's taken over half an hour. Before I think it took ~10min, but I'll run both versions tonight with less other things going on the system to get a difference.

Once I was sure it was a major slowdown, I killed it to try to play with OpenMP. Just to verify that it does actually parallelize.

[effigies]

For ds031/sub-01 (9 images):

Alignment	OMP_NUM_THREADS	Time
Aligning to first image		16m
Aligning to first image	7	5m
Unbiased template		1h46m
Unbiased template	7	1h21m

---

For ds114/sub-07 (2 images):

Alignment	OMP_NUM_THREADS	Time
Aligning to first image		1m13s
Aligning to first image	7	1m03s
Unbiased template		1m15s
Unbiased template	7	1m06s

[effigies]

Re: ds031, it's unclear whether we'd get a better speed-up profile if the number of images matched the number of threads; it could be that the parallel sections are going from 9 to 2. But even if so, it looks like the serial component for constructing an unbiased template is ~74min, and maximum concurrency might bring us down to 77-78min.

Similarly, for a simple alignment, it looks like we have a serial section of ~2.5min with maximum concurrency reducing to 3.6-3.7min.

I would say it makes sense to parallelize to min(num_images, omp_nthreads), which keeps small merges from eating up all the cores to little benefit, and to make unbiased templates optional. Given the low additional cost for a small number of input images, it could also make sense to make unbiased templates the default for fewer than N images (and I'll work out what a reasonable N is).

[chrisgorgo]

That's really long! I agree with your suggestions.

…

On Thu, Jul 27, 2017 at 8:13 AM, Chris Markiewicz ***@***.***> wrote: Re: ds031, it's unclear whether we'd get a better speed-up profile if the number of images matched the number of threads; it could be that the parallel sections are going from 9 to 2. But even if so, it looks like the serial component for constructing an unbiased template is ~74min, and maximum concurrency might bring us down to 77-78min. Similarly, for a simple alignment, it looks like we have a serial section of ~2.5min with maximum concurrency reducing to 3.6-3.7min. I would say it makes sense to parallelize to min(num_images, omp_nthreads), which keeps small merges from eating up all the cores to little benefit, and to make unbiased templates optional. Given the low additional cost for a small number of input images, it could also make sense to make unbiased templates the default for fewer than N images (and I'll work out what a reasonable N is). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#591 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkpyexVy8_nc9J-6VvZLeJWF6sp57bks5sSKkZgaJpZM4Obqsu> .

[effigies]

Sounds good. Then this will depend on nipy/nipype#2130, which make the number of threads an input trait, so it can be set like so:

wf.connect([(t1_conform, t1_merge, [(('t1w_list', len), 'num_threads')])])

(Replacing len with a more correct function.)

[effigies]

Haha, wow. N=2. Going from 2 to 3 images increases from <2min to ~25min. I do not need to see the curve badly enough to keep going.

[chrisgorgo]

Code looks ok, but please look into the failing tests.

[effigies]

It's the stochastic ICA-AROMA bug. If it pops up again, I'll merge #611 before running another round of tests.