Sooo, I think the fat_mat_tableize.py is still probably in beta mode, sorry about the confusion.
Re. fat_mvm_prep.py: you mention .grid files, so I assume we are talking about tractography outputs (from 3dTrackID). If you have 8 “target” ROIs input as your network to track, then you would indeed have 87/2 = 28 possible white matter connections between pairs of targets. In general, the brain is not wired with everything connected to everything, and so you would probably have <28 connections found, in practice.
Ummm, I’m curious about the namual editing of the *.grid files. That should not be necessary. If your “-netrois …” file input to 3dTrackID has labels, then those get passed along—that is a preferable way to go to avoid hiccups along the way (and the *.niml.tract files output will have those labels, too, for viewing in SUMA). Labels can be attached to a file with @MakeLabelTable, happy to discuss that separately. If you really have to put the labels into the *.grid files separately, we can discuss that—the format is pretty straightforward (but not preferred). Seeing the note about *.netcc strikes me as likely something being incorrect about how the labels have been entered.
What program for group analysis are you intending to run? 3dMVM? That was what fat_mvm_prep.py was initially designed to help run things for, and that program’s assumptions didn’t allow for having missing data at a tract. So the program takes your set of *.grid files and purposefully extracts connections that exist across all subjects.
If you are aiming to run something like Gang’s newer Bayesian group analysis programs, then having missing connections can be handled. You should be able to use this option in fat_mvm_prep.py then:
-u, --unionize_rois :mainly for GRID files (shouldn't affect
NETCC files)-- instead of making the ROI
list by taking the *intersection* of all
nonzero-regions in the matrix, make the
list as the *union* of elements across the
group. In this case, there will likely be
some zeros in properties, where there were
no tracts found, and the assumption would be
that those zeros are meaningful quantities
in your modeling (likely only for special
purposes). Choose wisely!
… to get the union of connections or *.grid file matrix elements (not the intersection, as is default). Is that applicable for you?
The languishing fat_mat_tableize.py is meant to be a more general and nicer-interfaced program for all of this. That should be finished soome day…
ps: to check your editing of the *.grid files, this is what the top of a “labelled” grid file output would look like, where the labels here are boring strings “001”, “002”, “003”, etc. Basically, having the number of labels match the number of ROIs is important, as is having the “# WITH_ROI_LABELS” string in Line 3:
# 8 # Number of network ROIs
# 9 # Number of grid matrices
001 002 003 004 005 006 007 008
1 2 3 4 5 6 7 8
28138 0 19 0 1654 6 0 0
… with the rest of the NT matrix provided in the next rows, etc.