3dMVM - covariate of no interest?


I’m a little confused about specifying variables in 3dMVM when I have a quantitative covariate of no interest. My goal is to run a one-way ANOVA on some seed-based resting state data with 1 between-subjects variable, “Group” (3 groups: CON, POE, POME), and 1 within-subject variable “VolRemaining” (Volumes remaining after scrubbing), which is my covariate of no interest. According to AFNI documentation (https://afni.nimh.nih.gov/MVM), it seems like 3dMVM is more appropriate than 3dLME. The 3dMVM documentation examples feature more complicated models than a one-way ANOVA so I just wanted to confirm that I was setting up the model correctly - my 3dMVM code looks like this:

3dMVM -prefix /PATH/TO/OUTPUT/20200823_3dMVM_V2_24CON_21POE_14POME_infant_neo_cal_L_GSR_PosP001/3dMVM -jobs 5
-mask /PATH/TO/MASK/ClusterMean_3dMVM_t-stat_JointMask_Pos_P001.nii.gz
-bsVars “Group+VolRemaining”
-qVars “VolRemaining”
-num_glt 6
-gltLabel 1 CON -gltCode 1 ‘Group : 1CON’
-gltLabel 2 POE -gltCode 2 'Group : 1
-gltLabel 3 POME -gltCode 3 ‘Group : 1POME’
-gltLabel 4 CONvPOE -gltCode 4 'Group : 1
-gltLabel 5 CONvPOME -gltCode 5 'Group : 1
-gltLabel 6 POEvPOME -gltCode 6 'Group : 1
-dataTable @datatable.txt

datatable.txt is as follows:
Subj Group VolRemaining InputFile
BB1027_V2_17July2017 CON 108.8644068 BB1027_V2_17July2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1065_V2_12Feb2018 CON -117.1355932 BB1065_V2_12Feb2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1076_V2_25Jan2018 CON 30.86440678 BB1076_V2_25Jan2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1078_V2R_10April2018 CON -333.1355932 BB1078_V2R_10April2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1089_V2_11July2018 CON 132.8644068 BB1089_V2_11July2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1096_V2R_19Jul2018 CON -339.1355932 BB1096_V2R_19Jul2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1099_V2R_27Aug2018 CON -54.13559322 BB1099_V2R_27Aug2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1106_V2_12Jul2018 CON 82.86440678 BB1106_V2_12Jul2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1108_V2_29Aug2018 CON 223.8644068 BB1108_V2_29Aug2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1115_V2R_19Oct2018 CON -80.13559322 BB1115_V2R_19Oct2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1116_V2R_30Oct2018 CON 104.8644068 BB1116_V2R_30Oct2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1117_V2R_16Oct2018 CON -89.13559322 BB1117_V2R_16Oct2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1120_V2_10Sep2018 CON -73.13559322 BB1120_V2_10Sep2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1133_V2_12Dec2018 CON -40.13559322 BB1133_V2_12Dec2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1139_V2_16Jan2019 CON 96.86440678 BB1139_V2_16Jan2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1140_V2_06May2019 CON 96.86440678 BB1140_V2_06May2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1148_V2_01Mar2019 CON -268.1355932 BB1148_V2_01Mar2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1157_V2_29Jul2019 CON 154.8644068 BB1157_V2_29Jul2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1159_V2_8Apr2019 CON 151.8644068 BB1159_V2_8Apr2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1165_V2_09Aug2019 CON -285.1355932 BB1165_V2_09Aug2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1166_V2_4Nov2019 CON -326.1355932 BB1166_V2_4Nov2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1203_9Dec2019_V2 CON -79.13559322 BB1203_9Dec2019_V2/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1205_V2_2Dec2019 CON -199.1355932 BB1205_V2_2Dec2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1216_V2_16Jan2020 CON -282.1355932 BB1216_V2_16Jan2020/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1045_V2_30AUG2017 POE -48.13559322 BB1045_V2_30AUG2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1056_V2_14NOV2017 POE -168.1355932 BB1056_V2_14NOV2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1057_V2_5Feb2018 POE 163.8644068 BB1057_V2_5Feb2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1103_V2_31May2018 POE 88.86440678 BB1103_V2_31May2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1113_V2_6Aug2018 POE 203.8644068 BB1113_V2_6Aug2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1121_V2_04Sep2018 POE -150.1355932 BB1121_V2_04Sep2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1127_V2_06Dec2018 POE -124.1355932 BB1127_V2_06Dec2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1130_V2R_18Dec2018 POE 188.8644068 BB1130_V2R_18Dec2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1138_V2_06Dec2018 POE 38.86440678 BB1138_V2_06Dec2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1151_V2_26Feb2019 POE 253.8644068 BB1151_V2_26Feb2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1155_V2_10Jun2019 POE -153.1355932 BB1155_V2_10Jun2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1156_V2R_03Jul2019 POE -253.1355932 BB1156_V2R_03Jul2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1164_V2_7Oct2019 POE 173.8644068 BB1164_V2_7Oct2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1172_V2_19Aug2019 POE 121.8644068 BB1172_V2_19Aug2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1173_19Aug2019_V2 POE -201.1355932 BB1173_19Aug2019_V2/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1180_10Sept2019_V2 POE -131.1355932 BB1180_10Sept2019_V2/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1189_V2_5Nov2019 POE 151.8644068 BB1189_V2_5Nov2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1190_V2_29Oct2019 POE -40.13559322 BB1190_V2_29Oct2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1199_V2_15Jan2020 POE 120.8644068 BB1199_V2_15Jan2020/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1214_V2_21Feb2020 POE 166.8644068 BB1214_V2_21Feb2020/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1219_V2R_28Jan2020 POE -317.1355932 BB1219_V2R_28Jan2020/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1024_V2R_4May2017 POME 240.8644068 BB1024_V2R_4May2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1029_V2_18May2017 POME 29.86440678 BB1029_V2_18May2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1033_V2_21July2017 POME -202.1355932 BB1033_V2_21July2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1044_V2_26Sept2017 POME 107.8644068 BB1044_V2_26Sept2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1051_V2_11Aug2017 POME 171.8644068 BB1051_V2_11Aug2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1054_V2_20Sept2017 POME 169.8644068 BB1054_V2_20Sept2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1067_V2_07Mar2018 POME -189.1355932 BB1067_V2_07Mar2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1069_V2R_14Dec2017 POME 47.86440678 BB1069_V2R_14Dec2017/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1084_V2_6June2018 POME 145.8644068 BB1084_V2_6June2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1098_V2_01Aug2018 POME 93.86440678 BB1098_V2_01Aug2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1101_V2R_13June2018 POME 184.8644068 BB1101_V2R_13June2018/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1143_V2_14Mar2019 POME 197.8644068 BB1143_V2_14Mar2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1147_V2_01May2019 POME 231.8644068 BB1147_V2_01May2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz
BB1191_V2_24Nov2019 POME 62.86440678 BB1191_V2_24Nov2019/infant_neo_cal_L_000_INDIV/WB_Z_ROI_001.nii.gz

Is it correct to have bsVars as “Group+VolRemaining” and -qVars as “VolRemaining” if I want to look at the main effect of Group while covarying for VolRemaining?

I have also mean-centered the VolRemaining variable rather than including the raw values - is that ok?

Thank you so much for your help!


1 within-subject variable “VolRemaining”

I assume that VolRemaining does not vary within subject. If so, it’s a between-subjects, not within-subject, quantitative variable.

-bsVars “Group+VolRemaining” \

Is “VolRemaining” supposed to be different between the two groups? In addition to proper centering, an alternative model is

-bsVars “Group*VolRemaining” \

Hi Gang,

Thanks for your response!

Yes, VolRemaining does not vary within subject - thanks for pointing out that it should be a between-subjects quantitative variable. Is it still appropriate to specify that in the code with the -qVars “VolRemaining” option?

VolRemaining is significantly different between two of my groups (between CON and POME), so I want to covary for it to ensure that any group differences are not due to this covariate of no interest. If I’m not interested in the interaction between Group and VolRemaining, would it be better to model it as -bsVars “Group+VolRemaining” or -bsVars “Group*VolRemaining” ?


Is it still appropriate to specify that in the code with the -qVars “VolRemaining” option?

Yes, that’s fine.

VolRemaining is significantly different between two of my groups (between CON and POME)

You may want to center each group separately:


and then set

-qVarCenters 0

If I’m not interested in the interaction between Group and VolRemaining, would it be better to
model it as -bsVars “Group+VolRemaining” or -bsVars “Group*VolRemaining” ?

The model should be built per the underlying data generative mechanism without regard to the research interest. In that sense, I would consider -bsVars “Group*VolRemaining”

Re: centering, thank you for sharing the link! Based on the section “When to center within- or across-groups?” it seems like the overall idea there is to use centering to get rid of within-group variability in order to better examine between-group differences. In my case, the covariate of no interest is not linked to group status and my goal isn’t to necessarily get rid of within-group variability in motion, but rather to get rid of between-group differences in motion to ensure that my group differences cannot be attributed to differences in motion. It seems that if I were to center the motion variable within-group then I would be eliminating within-group variability, but that wouldn’t address the between-group differences in motion. In order to best eliminate between-group differences in motion (continuous covariate of no interest), I think I would still have to demean across all groups?

Thank you!

If you want to interpret the group difference at the overall mean of VolRemaining, then it does make sense to perform global centering.

Great, thanks!!


Hello again!

I’ve been running 3dMVM on seed-based resting state data using a bunch of different seeds and it is working for all of my seeds except two (L/R calcarine ROI), where it will read the input files but then throws the following error:

Reading input files now…

Reading input files: Done!

If the program hangs here for more than, for example, half an hour,
kill the process because the model specification or the GLT coding
is likely inappropriate.

Possible reasons:

0) Make sure that R packages afex and phia have been installed. See the 3dMVM
help documentation for more details.

1) Inappropriate model specification with options -bsVars, -wsVars, or -qVars.
Note that within-subject or repeated-measures variables have to be declared
with -wsVars.

2) Incorrect specifications in general linear test coding with -gltCode.

3) Mistakes in data table. Check the data structure shown above, and verify
whether there are any inconsistencies.

4) Inconsistent variable names which are case sensitive. For example, factor
named Group in model specification and then listed as group in the table header
would cause grief for 3dMVM.

5) Not enough number of subjects. This may happen when there are two or more
withi-subject factors. For example, a model with two within-subject factors with
m and n levels respectively requires more than (m-1)*(n-1) subjects to be able to
model the two-way interaction with the multivariate approach.

** Error: 
   Quitting due to model test failure...

I've checked each of the possible reasons and all of them are satisfied (also the model runs when I input data from any other seed in there so I don't think it's an issue with the model). I've also checked the single-subject input files and they seem to be in order as well. Weirdly, I previously ran Group+VolRemaining (when I was testing models) and that ran with no issues, but now with Group*VolRemaining it is throwing the error. Any ideas for what might be the cause?

For reference, this is what my code looks like:


3dMVM -prefix /PATH/TO/OUTPUT/3dMVM -jobs 5	\
	-mask /PATH/TO/MASK/ClusterMean_3dMVM_t-stat_JointMask_Pos_P001.nii.gz	\
	-bsVars "Group*VolRemaining"	\
	-qVars "VolRemaining"	\
	-num_glt 6	\
	-gltLabel 1 CON -gltCode 1 'Group : 1*CON'	\
	-gltLabel 2 POE -gltCode 2 'Group : 1*POE'	\
	-gltLabel 3 POME -gltCode 3 'Group : 1*POME'	\
	-gltLabel 4 CONvPOE -gltCode 4 'Group : 1*CON -1*POE'	\
	-gltLabel 5 CONvPOME -gltCode 5 'Group : 1*CON -1*POME'	\
	-gltLabel 6 POEvPOME -gltCode 6 'Group : 1*POE -1*POME'	\
	-dataTable	@datatable.txt


Thank you!

it is working for all of my seeds except two (L/R calcarine ROI)

Most likely the problem is that the testing failed because 3dMVM could not find the small region limited by the mask. A workaround solution is to not use a mask, and let the program go through the whole brain. You can later apply the mask to the output if you prefer.

Masking afterwards in the 3dClusterize step worked well - thanks for the suggestion!

Hi again,

Another (follow-up) question about covariates. I am running ANCOVA using 3dMVM on seed-based resting state data with 3 between-subjects variables: “Group” (three groups; this is the variable of interest), “VolRemaining” (volumes remaining after scrubbing) and “Birthweight.”

I’d like to incorporate both VolRemaining and Birthweight as covariates of no interest into the model. Previously when I only covaried for VolRemaining, the model was “Group*VolRemaining” but now with 2 covariates of interest I’m not sure how best to structure the model for -bsVars.

I think the 3dMVM code would look something like this:
3dMVM -prefix /PATH/TO/OUTPUT/3dMVM -jobs 5
-mask /PATH/TO/MASK/mask.nii.gz
-bsVars “MODEL”
-qVars “VolRemaining,Birthweight”
-num_glt 6
-gltLabel 1 CON -gltCode 1 ‘Group : 1CON’
-gltLabel 2 POE -gltCode 2 'Group : 1
-gltLabel 3 POME -gltCode 3 ‘Group : 1POME’
-gltLabel 4 CONvPOE -gltCode 4 'Group : 1
-gltLabel 5 CONvPOME -gltCode 5 'Group : 1
-gltLabel 6 POEvPOME -gltCode 6 'Group : 1
-dataTable @datatable.txt

Based on the 3dMVM help page, it seems like “Group*VolRemaining + Birthweight” or “Group + VolRemaining + Birthweight” might be appropriate for -bsVars? Is it correct to have -qVars as “VolRemaining, Birthweight” if I want to look a the main effect of Group while covarying for VolRemaining and Birthweight?

Thank you!


You could have

-bsVars “GroupVolRemaining+GroupBirthweight”


-bsVars “Group*VolRemaining+Birthweight”


-bsVars “Group+VolRemaining+Birthweight”

No one knows in advance which model accounts for the data better than the others. I would just try the first model and see how it pans out. Is “VolRemaining” the number of TRs after censoring?

Hi Gang,

Thanks for the suggestions! I’ll try out the first model and go from there.

Yes, VolRemaining is the number of TRs after censoring (scrubbing).