[VoxBo] rfx analysis

[Daniel Y Kimberg]

marina bedny wrote:
> I just ran a test group rfx glm to make sure that I get the same
> answer whether I use a contrast vector specified in contrasts.txt vs.
> when I specify the vector myself. I don't. I'm pretty sure that using
> the contrasts.txt file gives you the wrong answer.
>
> As part of my glm's I use derivatives as covariates of no interest,
> in terms of the order in which the derivatives appear in the g matrix
> they are interspersed with the covariates of interest. Each
> derivative follows it's covariate of interest. However, I'm not sure
> how it's treated by the vbmakeglm tool when applied to rfx. I think
> the derivatives (covariates of no interest) are put at the back of
> the line along with the other covariates of no interest. My newest
> guess is that voxbo only screws up by not putting the covariates of
> no interest in the back when the covariate of no interest is the very
> first added before any covariates of interest.

Indeed, part of the problem seems to be that some parts of VoxBo
assume the covariates are going to get re-ordered, and others don't.

> When I look at one of the .map files for running the analysis each
> way here is what I get:
>
> using specified contrast: /jet2/mbedny/PolyHom/group/Inc-ConNTesbeta
> contrast_vector: 0 0 0 0 0 0 0 0 0 0 -1 1 -1 1 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0
>
> using contrasts.txt: /jet2/mbedny/PolyHom/group/Amb-ControlNTesbeta_test
> contrast_vector: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 1 0 -1
> 0 1 0 0 0 0 0 0 0 0 0
>
> the reason I think that the second one is incorrect is because all
> the .map files are empty, and because when I specify the contrast
> myself the results make perfect sense.

It does look like vbstatmap (used by RFX to generate the map file)
assumes the contrast vector you pass has the covariates of no interest
pushed the to the back.  So it does the right thing in the first case,
but since contrasts from contrasts.txt aren't sorted, it's doing the
wrong thing.  In your case it caused all zeros, but in some cases it
could cause maps that are just plain wrong.

This is indeed a serious bug.  It won't come up if all your covariates
of no interest are pushed to the back (use glminfo to check), or if
you use a contrast that only involves covariates that occur before the
first covariate of no interest.  It also won't come up if you specify
a full contrast vector with the covars of interest coming first, and I
believe it should work if you only specify the covariates of interest.
I don't believe this bug affects vbdumpstats, but I will double-check
that to be sure.

I've made a fix for this in my code, and I'll release it once I've had
a chance to clean up and do some more thorough testing.  In part, the
fix outlaws specifying the full contrast vector -- for purposes of
contrasts, only the covariates of interest exist, whether it's in an
RFX script or a call to vbdumpstats or vbstatmap.  So unless you
specify just the covariates of interest, you'll get an error.  This
will necessitate changing some existing RFX scripts, but will make
everything consistent, and will much more reliably generate errors
when things are out of sync.

> I think this is something quite important because if the contrast is
> not correct there is no error message. You can get results that have
> nothing to do with what you think you're actually testing.

All true, and it's my bug.  I'll try to post the updated code
tomorrow, and I apologize for and problems this has caused.  I do
think the contrasts.txt file will make life a lot easier in the long
run, but obviously there are still kinks to be worked out.

dan