Fixelcfestats concerns

[jdtournier]

Hi Steven,

@smeisler

The first was that [WARNING] A total of 31890 fixels do not possess any streamlines-based connectivity; these will not be enhanced by CFE, and hence cannot be tested for statistical significance. I’ve seen this discussed elsewhere, but this number seems especially high, given there are 517176 fixels in the template space. Is this something I should be particularly concerned about, and if so, what do you suggest for QC?

I wouldn’t be overly concerned about this. It’ll depend on what thresholds were used in the fixel segmentation step (fod2fixel), and in the tractography step. For example, if fixels are included in the fixel mask that have smaller amplitudes than allowed in the tractography, it’s not surprising to find many fixels without any corresponding streamlines, which would give you this warning.

If you’re really concerned about this, you could try using the suggestion from @rsmith, and generate an alternative mask using tck2fixel & mrthreshold, and then use mrcalc to check the difference between the mask you used and the tractography-derived one to see which fixels were excluded, and satisfy yourself that they’re not in locations you’d consider important for your analysis.

@smeisler

The second, is Design matrix conditioning is poor (condition number: 699.547); model fitting may be highly influenced by noise.
My design matrix is a text file in which each line looks like:
“0 METRIC COVAR1 COVAR2” (without "s, values filled in) and is specific for a subject.

Is your first column genuinely filled with zeros? If so, that would definitely lead to extremely poor conditioning!

I assume (hope?) this column is actually coded as zeros & ones to represent group membership? If so, then the poor condition number is unexpected, and suggests that at least two of your columns are very strongly correlated. Definitely worth investigating if that’s the case…

Finally, if you have a column of zeros & ones, you’ll probably want to add a column of ones in there. I’d also suggest you might want to change that group membership column to -1 & 1 respectively, as that tends to help with interpretation of the coefficients. See this response from @rsmith for a more detailed explanation of these issues.

Actually, I just spotted that your later post suggests this is actually a column of ones (is that correct)? In which case, it’s still very much worth trying to figure out what is causing the rank deficiency. Assuming your columns are [ 1 cog.score sex handedness ], then I really wouldn’t expect such strong correlations between the columns…

@smeisler

My last concern is that I run into out of memory issues after devoting 256 GB of memory to the process. Do you have any advice for memory concerns in large cohorts?

Wow. Not sure what to do here, that’s a lot of subjects! @rsmith has already done a huge amount of work to reduce memory requirements, so assuming you’re using the latest version of the code, I’m not sure what more we can do. We’ll need to think long and hard about this… But it’s a least reassuring that it runs for a subset of subjects.

@smeisler

However, the effect sizes are really small, with beta ranging from about -.001 to .003. Is my intuition about the beta1.mif file correct?

Given the way your design matrix is constructed, your beta coefficients should correspond to the impact of a unit increase in cognitive score on logFC. So it implicitly depends on the units of your cognitive score, and what kind of range of values you expect to see. For example, if you expect to see differences in cognitive score of the order of 30 points in your cohort, then that corresponds to a e.g. 0.003 × 30 = 0.09 difference in logFC (which translates to a e^0.09 ≈ 10% change in FC). Hard to know what’s right without knowing more about your cognitive score – but hopefully this will be enough for you to figure out whether your values are reasonable.

Worth also pointing out that these effect sizes are probably not to be trusted until you fix that rank deficiency issue…