Include gamma/dgamma convolution in contrast (`nipype.interfaces.fsl.model.Level1Design`)

[TheChymera]

With the following inputs (report.rst) I get the following fsl.mlodel.Level1 output: run0.fsf.

I would like to get something like this: run0.fsf. The meaningful diff being:

333c333
< set fmri(con_real1.2) 0.0
---
> set fmri(con_real1.2) 1.0

I have tried to look at the source code, but I cannot figure out where these lines are generated. Can you help me out?

This is really vital, since without this change, the gamma/dgamma convolution for FSL via nipype is plainly and objectively broken. All the convoluted timecourses should be included in the contrast, and currently they are not.

[satra]

@TheChymera - FSL's level1design uses templates and populates them via arguments, internal estimates.

the templates are here: https://github.com/nipy/nipype/tree/master/nipype/interfaces/fsl/model_templates

the relevant templates get picked up in the FSL level1design code.

This is really vital, since without this change, the gamma/dgamma convolution for FSL via nipype is plainly and objectively broken. All the convoluted timecourses should be included in the contrast, and currently they are not.

diff you are pointing to has to do with contrast specifications. and that would be set to 1 or 0 or whatever weight as you specify in building your contrasts. this should go into the contrasts input of level1design. however, you only have one condition in your session_info:

* session_info : [
{'cond': [{'amplitudes': [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1], 
           'duration': [1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0], 
           'name': 'ev0', 
           'onset': [50.0, 90.0, 130.0, 170.0, 210.0, 250.0, 290.0, 330.0, 370.0, 410.0, 450.0, 490.0, 530.0, 570.0, 610.0]}], 'hpf': 225.0, 'regress': [], 'scans': '/mnt/overflow/opfvta/l1_none_gamma_work/_ind_type_153/specify_model/sub-5685_ses-ofM_task-JPogP_acq-EPI_run-0_cbv.nii.gz'}]

[TheChymera]

@satra Sadly that doesn't work like that, since e.g. this report.rst will generate this run0.fsf, which includes 4 regressors, of which only the first and third are added to the contrast:

# Real contrast_real vector 1 element 1
set fmri(con_real1.1) 1.0

# Real contrast_real vector 1 element 2
set fmri(con_real1.2) 0.0

# Real contrast_real vector 1 element 3
set fmri(con_real1.3) 1.0

# Real contrast_real vector 1 element 4
set fmri(con_real1.4) 0.0

# Display images for contrast_orig 1
set fmri(conpic_orig.1) 1

# Title for contrast_orig 1
set fmri(conname_orig.1) "all"
# Real contrast_orig vector 1 element 1
set fmri(con_orig1.1) 1.0

# Real contrast_orig vector 1 element 2
set fmri(con_orig1.2) 1.0

The problem, once convolution is applied, is that extra regressors get generated quietly by the interface, and there appears to be no option to control whether they are added to the contrast.

[satra]

if you are referring to these two:

# Real contrast_real vector 1 element 2
set fmri(con_real1.2) 0.0
...
# Real contrast_real vector 1 element 4
set fmri(con_real1.4) 0.0

these are the temporal derivatives and yes FSL doesn't support using them for contrasts. and in traditional models you wouldn't add them to the contrast vector. is there a specific use case for wanting to add temporal derivatives to contrast estimation? what would that mean?

[TheChymera]

these are the temporal derivatives

Now that I look at the waveshape, this does seem to be the case. But what does that mean regarding the convolutions? Are all of them applied inside the first regressor? This seems highly unlikely, since estimating their contributions (i.e. their multiplier when adding them together) is what the GLM does.

[satra]

anything attached to conditions are convolved, including temporal derivatives. the only thing the fsf file is telling feat is to not include that regressor in estimating the contrast.

regressors like motion, or other elements (artifact onsets), would not be convolved.

in your example (and you can take a look at design.png which would be created by the modeling step), you will see that the design matrix has those first four columns. each of those columns are convolved with the hrf basis.

[TheChymera]

Ok, I understand now, it appears this was indeed not a bug, but a misunderstanding of FSL's convolution process. I thought that e.g. the double gamma functions in the dgamma/hrf method would be modeled separately, so as to better account for the range of possible response shapes. After inspecting the relevant documentation again, this seems to only be doable via the custom option.