Message during batch fitting

[Claire Kelly]

Hi Gary,

I have gone through all of the processing steps to apply NODDI to my data, and have produced ODI and FICVF maps that look reasonable I think. However, for a few of my subjects (about 5%), I receive the following message during their batch fitting:

MException

Properties:
identifier: 'MATLAB:svd:matrixWithNaNInf'
message: 'Input to SVD must not contain NaN or Inf.'
cause: {0x1 cell}
stack: [9x1 struct]

Despite this message, the batch fitting appears to continue and finish without problems, and the resulting ODI and FICVF maps look normal.

I have viewed the error_code.nii for these subjects and have noticed that they each contain 1 voxel with an intensity of 2. The non-zero voxels are in different locations in the brain for each subject (sometimes they are at the edge, sometimes they are in the middle). Other subjects that don’t get this message during batch fitting don’t have any non-zero values in their error_code.nii.

Do you have any idea what this message might mean and what I could do about it?

Thanks in advance for your help.

Claire

[Hui Zhang]

Hi Claire,

I am glad that you have discovered the error_code.nii which is designed to record the voxels with fitting difficulties.  It looks like the problem is limited to very specific few voxels, which is good.  To figure out what has gone wrong with these few voxels, you need to look at the raw DWI signals at these voxels.  If you need help, can you post the values for one such voxel?

Gary

Claire

--
You received this message because you are subscribed to the Google Groups "NODDI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noddi+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Claire Kelly]

Hi Gary,

I have put the values for one of these voxels with a fitting error in the attached spreadsheet, so if you could have a look at that, that would be great (there are 77 volumes in total, so I have put the value for every volume). For some additional information, I've also put the mean value of every voxel at every volume, and the standard deviation, and the minimum and maximum values. Additionally, the DWIs have two b-value shells, and I have put the values before and after I accounted for the different TEs between the two shells (I accounted for the different TEs by dividing every volume in each shell by the average b=0 measurement for that shell, as you suggested in a previous post on this forum). I accounted for the different TEs before running NODDI, however there are some very large values in these DWIs, which are due to a few voxels at the outer edges/slices of the brain, which is why I've also put the values before accounting for the different TEs. 

I hope this makes sense. Let me know if any additional information would help.

Thanks,

Claire 

[Hui Zhang]

Hi Claire,

It will be great if you can send me a mat file that includes all the measurements at a voxel with fitting issue, before and after your TE correction, as well as the protocol.

Thanks.

Gary

[Emil Ljungberg]

Hi,

I am running into a similar problem running the NODDI analysis on my system for some spinal cord data. It stops right in the beginning of the script and halts the process after the error. I am just testing out the protocol in a small mask.

>> batch_fitting('NODDI_roi.mat', protocol, noddi, 'FittedParams.mat', 4);
78 of voxels to fit
Error using parallel_function (line 589)

Input to SVD must not contain NaN or Inf.

Error stack:
pinv.m at 29
FitLinearDT.m at 35
GridSearchRician.m at 57
ThreeStageFittingVoxel.m at 66
batch_fitting>(parfor body) at 95
Error in batch_fitting (line 88)
parfor i=split_start:split_end

When I look through my data I cannot find any particularly strange voxels and when I load the NODDI_roi.mat in matlab I cannot find any inf or NA elements in the or matrix. Where do you recommend me to start looking for potential errors in my data?

When running the analysis I follow the exact steps outlined on the website. Thanks very much for making this analysis publicly available and providing this forum for discussion, much appreciated!

Best Regards
Emil Ljungberg
UBC

[Emil Ljungberg]

Hi again,

I actually managed to figure out where the error was and thought I might share it here as well.

The thing is that the NODDI protocol that we have running on our scanner actually includes a [0,0,0] direction for the b=700, which doesn't seem to be the case for protocols on other scanners. Is there any thoughts about that this might decrease the performance of the fit procedure? 

At the end of FSL2Protocol there is a section that normalize the gradient vectors using the norm of the vector. However, if the vector is [0,0,0] the norm is 0 and the division yields a NAN result, which later on will throw an error in the fit procedure. I added just one line to ensure that if the gradient vector is [0,0,0] that it will not normalize that vector but instead leave it as is. 

Would this be valid approach or is a [0,0,0] vector not preferable in the fit procedure?

% make sure the gradient directions are unit vectors

for i=1:protocol.totalmeas

    if ~isequal(protocol.grad_dirs(i,:), [0 0 0])

        protocol.grad_dirs(i,:) = protocol.grad_dirs(i,:)/norm(protocol.grad_dirs(i,:));

    end

end..

Thank you very much for providing a great and easy to use software package!

Best

Emil Ljungberg

UBC

[Hui Zhang]

Ok.  Depending on what happens when the direction is [0 0 0] and the b-value is not 0.  Do you get a b=0 image in return?  If that is the case, you can instead, set the b-value to 0 and set the direction to [1 0 0] (or any other non-zero vectors).

Gary

--

You received this message because you are subscribed to the Google Groups "NODDI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noddi+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emil Ljungberg]

Hi Gary, 

Thanks for your answer, I realize having [0 0 0] with a non zero b doesn’t really make any sense, sorry for that. I update our protocol to instead have a b=0 and [1 0 0] as you suggested. And yes, I guess the point was to have a B0-volume.

Thanks!

Emil

You received this message because you are subscribed to a topic in the Google Groups "NODDI" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/noddi/7MP7-AGzrU4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to noddi+un...@googlegroups.com.