Error using OspreyProcess with job file, but not GUI - Error in osp_WriteBIDsTable

I am setting up a pre-processing pipeline for single voxel PRES data (Siemens dicom), and I am getting this error when I load my job.m file, but not when I manually select the files in the GUI.

Error message
... done.
 Elapsed time 116.678308 seconds
Error using writetable
FILENAME must be a non-empty character vector or string scalar.

Error in osp_WriteBIDsTable (line 13)
writetable(Table,[OutLoc,'.txt'],'Delimiter','\t'); % Write table with tab delimiter

Error in OspreyProcess (line 830)
osp_WriteBIDsTable(MRSCont.QM.tables, [outputFolder filesep 'QM_processed_spectra'])

Error in osp_onProc (line 37)
    MRSCont = OspreyProcess(MRSCont);
 
Error while evaluating UIControl Callback.

When I run the job.m file the Load Data stage runs correctly- all files are found based on my code, and PDFs are generated. There is a MRSCont file. However the Process Data stage generates no output and no changes in MRSCont file.

My data is organised into BIDS folders. It’s dicom data, and as per Osprey wiki guide here I made sure that each dicom file is in separate folder. In the job.m file I specify the location of files based on the pattern for folder names (instead of listing all the filepaths individually)- and I need this to stay that way as we are still early in data collection process and I want to set up the pipeline to run once we have all the data.

Folder structure

Here is how I have my data organised (only included two participants to not make it too long). In this script I am only analysing ACC data, and I intend to create a separate job file for the Hippocampus data.

.
├── sub-102
│   ├── ses-MRI1
│   │   └── mrs
│   │       ├── ACC
│   │       │   ├── mrsref
│   │       │   │   └── sub-102_ses-MRI1_voi-ACC_acq-pres_mrsref.dcm
│   │       │   └── svs
│   │       │       └── sub-102_ses-MRI1_voi-ACC_acq-pres_svs.dcm
│   │       └── LtHippocampus
│   │           ├── mrsref
│   │           │   └── sub-102_ses-MRI1_voi-LtHippocampus_acq-pres_mrsref.dcm
│   │           └── svs
│   │               └── sub-102_ses-MRI1_voi-LtHippocampus_acq-pres_svs.dcm
│   └── ses-MRI2
│       └── mrs
│           ├── ACC
│           │   ├── mrsref
│           │   │   └── sub-102_ses-MRI2_voi-ACC_acq-pres_mrsref.dcm
│           │   └── svs
│           │       └── sub-102_ses-MRI2_voi-ACC_acq-pres_svs.dcm
│           └── LtHippocampus
│               ├── mrsref
│               │   └── sub-102_ses-MRI2_voi-LtHippocampus_acq-pres_mrsref.dcm
│               └── svs
│                   └── sub-102_ses-MRI2_voi-LtHippocampus_acq-pres_svs.dcm
├── sub-103
│   └── ses-MRI1
│       └── mrs
│           ├── ACC
│           │   ├── mrsref
│           │   │   └── sub-103_ses-MRI1_voi-ACC_acq-pres_mrsref.dcm
│           │   └── svs
│           │       └── sub-103_ses-MRI1_voi-ACC_acq-pres_svs.dcm
│           └── LtHippocampus
│               ├── mrsref
│               │   └── sub-103_ses-MRI1_voi-LtHippocampus_acq-pres_mrsref.dcm
│               └── svs
│                   └── sub-103_ses-MRI1_voi-LtHippocampus_acq-pres_svs.dcm

I have read through the osp_WriteBIDsTable.m and OspreyProcess files to try and find the reason but I wasn’t able to conclude much. I observed that the OspreyProcess command does not generate MRSCont.QM and this data is referenced in the error message, then I think it only tells us that there is no data to write to the table, or that it cannot find some files? But I don’t understand why, since everything works and I select the same files with the GUI and it works fine.

I have spent over a week trying to fix this, so some guidance would be very appreciated, thank you!

It may be helpful if you were able to share your job.m file.

I’m not clear whether during your troubleshooting you put a break point somewhere in the lines just before the error occurs, and had a look at what is different in terms of variables/their content between running GUI and job.m?

Hi @juliam98,

I would guess this is an issue with how outputFolder is defined in your job.m file – but, as @peter suggests, we’d need to see that file to be sure. To help diagnose, you could also try adding these lines just above line 830 in OspreyProcess (mentioned in the error report):

outputFolder
class(outputFolder)

This will just cause Matlab to display the contents and type of the outputFolder variable, which might make the issue apparent. I suspect it’ll report this as a cell array, which would be incorrect.

By the way…

Great plan, I wish more projects figured out (and tested) the processing before collecting all their data.