Overview of problem
After specifying the model, as outlined in the first four steps of the DCM for evoked responses tutorial, inversion immediately fails with:
SPM26: spm_eeg_lgainmat 14:06:10 - 28/04/2026
----------------------------------------------------------------
Error using ft_read_headmodel (line 46)
file 'C:\Users\at16431\OneDrive - University of Bristol\Ashley_AD_EEG\Anna_AI_taskcodes\Berk_new\New_spm\SPM\SPM\canonical\single_subj_T1_EEG_BEM.mat' does not exist
What's going on
The dataset linked in the docs for DCM for evoked response, points to dcm-erp-tyrer.zip with the following hash:
sha256sum: 56f364b9db49f3a9d1623754fce063424227095b6eaf236d5069615de27d659b
The contents of this archive are a single subject's processed data in SPM format:
mfaeffspmeeg_examplecontrolsubject.mat
mfaeffspmeeg_examplecontrolsubject.dat
Loading these data using SPM and inspecting their existing inversion fields reveals two things: there are five inversions in total with two unique gain matrices, and crucially these gain matrices are not supplied:
D = spm_eeg_load('mfaeffspmeeg_examplecontrolsubject');
numel(D.inv)
% ans =
% 5
% Loop over all inversions
cellfun(@(x)(fprintf('Gain matrix file: %s with comment: %s\n', x.gainmat, x.comment{:})), D.inv, 'UniformOutput', false)
Gain matrix file: SPMgainmatrix_aeffspmeeg_8028_priming3_proc_1.mat with comment:
Gain matrix file: SPMgainmatrix_aeffspmeeg_8028_priming3_proc_1.mat with comment: ERP_CMM_NMDA_DCM_SENSOR_PRIMINGpmeeg_8028_priming3_proc.mat
Gain matrix file: SPMgainmatrix_mfaeffspmeeg_8028_priming3_proc_3.mat with comment: DCM_ERP_CMM_NMDA_DCM_SENSOR_PRIMINGpmeeg_8028_priming3_proc.mat
Gain matrix file: SPMgainmatrix_mfaeffspmeeg_8028_priming3_proc_3.mat with comment: DCM_30-Apr-2021
Gain matrix file: SPMgainmatrix_mfaeffspmeeg_8028_priming3_proc_3.mat with comment: DCM_30-Apr-2021
Due to the missing leadfields, SPM tries to compute one from the forward model. However that fails because the paths to the BEM surfaces are hardcoded in each inversion:
unique(cellfun(@(x)(x.forward.vol), D.inv, 'UniformOutput', false)')
ans =
2×1 cell array
{'/users/at16431/Documents/MATLAB/SPM/spm12/spm12/canonical/single_subj_T1_EEG_BEM.mat' }
{'C:\Users\at16431\OneDrive - University of Bristol\Ashley_AD_EEG\Anna_AI_taskcodes\Berk_new\New_spm\SPM\SPM\canonical\single_subj_T1_EEG_BEM.mat'}
The inversions appears to be using BEM surfaces derived from canonical meshes provided with SPM, however the paths to those files are local to the system used for respective inversions. And these paths don't automatically update over to a user's SPM installation unfortuntately.
Solution
Three possible paths forward:
- Supply the gain matrix along with processed data in the archive for maximum reproducibility
- Use same data and inversions, but provide a helper function to update paths for meshes etc on users' systems to their SPM installations
- Use same data, discard all existing inversions and create a forward model from scratch using SPM defaults
I vote for 1 > 3 > 2, as we've done the same in a reliable manner previously: https://github.com/pranaysy/MultimodalDCM
Overview of problem
After specifying the model, as outlined in the first four steps of the DCM for evoked responses tutorial, inversion immediately fails with:
What's going on
The dataset linked in the docs for DCM for evoked response, points to dcm-erp-tyrer.zip with the following hash:
The contents of this archive are a single subject's processed data in SPM format:
Loading these data using SPM and inspecting their existing inversion fields reveals two things: there are five inversions in total with two unique gain matrices, and crucially these gain matrices are not supplied:
Due to the missing leadfields, SPM tries to compute one from the forward model. However that fails because the paths to the BEM surfaces are hardcoded in each inversion:
The inversions appears to be using BEM surfaces derived from canonical meshes provided with SPM, however the paths to those files are local to the system used for respective inversions. And these paths don't automatically update over to a user's SPM installation unfortuntately.
Solution
Three possible paths forward:
I vote for 1 > 3 > 2, as we've done the same in a reliable manner previously: https://github.com/pranaysy/MultimodalDCM