extremely long run time for NODDI example/demo

[grlee77]

Expected Behavior

As part of the JOSS paper review, I was running a few of the demos. Mostly, these worked as expected and finished within a fairly short time (seconds to a few minutes). The NODDI demo however ran for hours until I eventually terminated it.

Current Behavior

I actually started the NODDI demo and forgot about it. I found that it was still running the following morning (at 100% CPU usage for a single core).

Possible Solution

I didn't look into the code closely, but based on the traceback after hitting Ctrl+C it was still running the fmincon minimization within ThreeStageFittingVoxel.

Two possible solutions (aside from any potential code refactoring/fixes):
1.) reduce the data size used if possible
2.) make a more prominent warning to the user about the expected runtime

Steps to Reproduce

1. From a Matlab terminal, run:

Matlab

model = noddi
qMRgenBatch(model)
noddi_batch

Context (Environment)

Matlab R2017a in linux

Detailed Description

Possible Implementation

[agahkarakuzu]

@grlee77 thank you for the feedback! Indeed, data fitting with the noddi model takes pretty long. This is the reason why we also included an accelerated implementation (AMICO) of the noddi.

In general, we don't performance claims, especially for complex models such as qMT. We have performance improvement plans for future releases, but for now, we would like to put most of our effort in bringing together as many as possible qMRI models together and give users an easy way to explore them.

[grlee77]

In general, we don't performance claims, especially for complex models such as qMT. We have performance improvement plans for future releases, but for now, we would like to put most of our effort in bringing together as many as possible qMRI models together and give users an easy way to explore them.

Sure, no problem. I just wanted to give a heads up in case this was unexpected or I was just doing something wrong on my end. I agree that having an open implementation that gives reasonable results is the appropriate first step and performance can always be improved as needed going forward.

[mathieuboudreau]

@agahkarakuzu Maybe instead of doing a continuous update of the progress during the for loop (which I'm against, it's slow and has been difficult to maintain for both GUI and command line), we could just fit a few voxels and provide the user with an estimated processing time for the entire dataset? Or, (even better), we could time each processing time for all the demo datasets, and give those numbers as a ballpark figure?