Error with Type-B Model

[nbabaee]

Hello,

I have an event-related experiment with 96 conditions (I also have random null trials in each run and I considered it as a condition). each subject completed 10 runs with 148 trials. I made a 148*97 design matrix for each run. when I run Type_B Model I receive the following error:

*** FITTING TYPE-B MODEL (FITHRF) ***
working on chunk 1 of 1.
Warning: Matrix is close to singular or badly scaled. Results may be
inaccurate. RCOND = 1.777872e-18.

In olsmatrix2 (line 67)
In GLMestimatemodel>fitmodel_helper (line 823)
In GLMestimatemodel (line 419)
In GLMestimatesingletrial (line 926)
In Untitled2 (line 15)
Error using olsmatrix2 (line 68)
Matrix is close to singular or badly scaled. Results may be inaccurate.
RCOND = 1.777872e-18.

Error in GLMestimatemodel>fitmodel_helper (line 823)
f = mtimescell(olsmatrix2(cat(1,design{:}),opt.lambda),data2); %
conditions x voxels

Error in GLMestimatemodel (line 419)
[results{1},hrffitvoxels,cache] = ...

Error in GLMestimatesingletrial (line 926)
results0 = GLMestimatemodel(designSINGLE,cellfun(@(x)
x(chunks{z},:,:,:),data,'UniformOutput',0), ...

I have tried GLMsingle with several changes in my data for example considering just one slice of volume images but I still get this error and it seems that the problem is with the design matrix.
I would appreciate it if you could guide me.

[kendrickkay]

Can you provide an image and or file containing your design matrix? Sent from iPhone Kendrick Kay

…

On Tue, Dec 3, 2024 at 6:00 AM nbabaee ***@***.***> wrote: Hello, I have an event-related experiment with 96 conditions (I also have random null trials in each run and I considered it as a condition). each subject completed 10 runs with 148 trials. I made a 148*97 design matrix for each run. when I run Type_B Model I receive the following error: *** FITTING TYPE-B MODEL (FITHRF) *** working on chunk 1 of 1. Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 1.777872e-18. In olsmatrix2 (line 67) In GLMestimatemodel>fitmodel_helper (line 823) In GLMestimatemodel (line 419) In GLMestimatesingletrial (line 926) In Untitled2 (line 15) Error using olsmatrix2 (line 68) Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 1.777872e-18. Error in GLMestimatemodel>fitmodel_helper (line 823) f = mtimescell(olsmatrix2(cat(1,design{:}),opt.lambda),data2); % conditions x voxels Error in GLMestimatemodel (line 419) [results{1},hrffitvoxels,cache] = ... Error in GLMestimatesingletrial (line 926) results0 = GLMestimatemodel(designSINGLE,cellfun(@(x) x(chunks{z},:,:,:),data,'UniformOutput',0), ... I have tried GLMsingle with several changes in my data for example considering just one slice of volume image but I still get this error and it seems that the problem is with the design matrix. I would appreciate it if you could guide me. — Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU2DEX3GDPQQQOZ342KNEL2DTC55AVCNFSM6AAAAABS4JTLFGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGYYDAMRTGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nbabaee]

Here is the image of the first run design matrix

and the design cell for all runs is
design.zip

Thanks

[kendrickkay]

See above. It appears that every single volume is labeled with the onset of some condition. This is going to cause estimation of the model to be problematic (as the error message indicated). Perhaps you should not code your "null trials" as an explicit condition? There needs to be sufficient data corresponding to baseline in order for the model to be estimatible. (There are polynomial terms that are used to model the baseline signal level.)

[nbabaee]

I'm sorry for not getting back to you sooner.
You are right. Null trials should be considered as baseline just like in a common GLM.
I changed the number of conditions to 96 and the HRF index was obtained as follows. As you can see, the HRF-index variation is low across voxels, Is it normal to have such results?

[kendrickkay]

That image result looks unusual, so something funny might be happening. Perhaps you can share the whole folder of figure outputs so we can diagnose?

[nbabaee]

Thanks.
Here you are.
GLMsingle_TypeB_fig.zip

[kendrickkay]

Also, are you sure you intend to code every new volume as corresponding to a new trial? That is a very aggressive design matrix and will be extremely challenging to estimate well.

[nbabaee]

I have a different stimulus for each volume image except for the null trials and I need the beta value of each stimulus. As you guided me, I should not consider null trials as a condition.
Do you mean that, except for null trials, not every volume should be considered a condition?

Thank you for your Time!

[kendrickkay]

I wouldn't say that "not every volume should be considered". I mean, the experiment is whatever you decided it should be. So, the proper thing to do would indeed to code every condition onset that you had.

My only speculation is that your design may be quite challenging to get estimates for. It will depend, I think, on how many repeated trials you have available (e.g. repeats across runs). The more you have, the better things are going to be.

[nbabaee]

How many trials are required for each condition? Some conditions are repeated five times, but I can merge them. For example, I have five different images of one person (each one repeated five times across all runs), and I can merge all of them to have one condition for that person.

[kendrickkay]

There is no strict requirement. If a single image is repeated five times great. The idea you suggest of merging all of the images of the same person is also a reasonable approach. But not necessary as long as you have repeats already.

[kendrickkay]

I looked at the figures. Take a look at runwiseFIR.png. The FIR estimates are delayed relative to the library. This means that something is a bit off. EIther you have a temporal offset bug (such that your stimuli actually start earlier than you coded them). Or, what did you specify for ? We now know the source of you were seeing in terms of the HRFindex being highly uniform ---> the data reallly "wants" a highly delayed HRF and so it makes sense that it is picking like the very last HRF (the most delayed one).

(Also, it looks like your TR is 3 s?)

[nbabaee]

You are right. Stimulus onset is .9s before the start of the data acquisition and lasts for 0.9s. TR=3s and delay in TR=1s. Stimulus onset is synchronized with the MR trigger in every volume.

[kendrickkay]

OK. I am not 100% sure in what you describe. But the main point appears to be that the HRF library isn't accurately capturing the observed timecourses (as revealed by the FIR plots), so that should ideally be fixed

[nbabaee]

This is my task design:

I upsampled the time series of each run and adjusted the sampling time to the stimulus onset using "tseriesinterp" function in Matlab (i.e. I Synchronized the beginning of each volume with the corresponding stimulus onset time). However, it seems there is still a problem. Please see the typeD_R2 figure, Is it normal?
You can find the full GLMsingle output figures here:
96C_resample_sessionindc_full.zip

[kendrickkay]

I looked at the figures. I don't think there is a problem. The signal strength is a bit weak, but that may be unavoidable given your experiment and long TR. The dmetric* figures and onoffR2 figures do indicate substantial signals, so that's good

[nbabaee]

Okay, I'm glad I can use this toolbox.
I appreciate your taking the time to solve my problem.
Happy New Year!