PhysIO with multiband and multiecho fMRI

[ejrise]

Hi Tapas Team,

I am using PhysIO (Tapas version 6.0.1) to get respiration and pulse regressors for 7T multiecho MRI data. The acquisiton has 84 slices, TR=2.1, 300 volumes, and a multiband factor of 4, so I have been attempting to implement the proposed MB workaround by setting nSlices = 84/4 = 21. The log files are Siemens VD. However, when I do this, I get the following error:

09-Feb-2024 17:06:50 - Failed 'TAPAS PhysIO Toolbox' Error using tapas_physio_log Number of slice event bundles does not match Nscans. Check parameters sqpar.Nscans, Ndummies and Nprep. (Matlab error: Array indices must be positive integers or logical values.) In file "/Volumes/GoogleDrive/My Drive/MATLAB/spm12/toolbox/PhysIO/code/utils/tapas_physio_log.m" (???), function "tapas_physio_log" at line 56. In file "/Volumes/GoogleDrive/My Drive/MATLAB/spm12/toolbox/PhysIO/code/sync/tapas_physio_get_onsets_from_locs.m" (???), function "tapas_physio_get_onsets_from_locs" at line 113. In file "/Volumes/GoogleDrive/My Drive/MATLAB/spm12/toolbox/PhysIO/code/sync/tapas_physio_create_scan_timing.m" (???), function "tapas_physio_create_scan_timing" at line 122. In file "/Volumes/GoogleDrive/My Drive/MATLAB/spm12/toolbox/PhysIO/tapas_physio_main_create_regressors.m" (???), function "tapas_physio_main_create_regressors" at line 165. In file "/Volumes/GoogleDrive/My Drive/MATLAB/spm12/toolbox/PhysIO/tapas_physio_cfg_matlabbatch.m" (???), function "run_physio" at line 1661.

I've tried different inputs for onset_slice that I've seen in other issue posts, such as [0:20], [1:21], or 10 (the "middle" slice). No matter what I input for this, I still get this error.

I also wanted to check that Tapas is compatible with multiecho data. It looks like tapas_physio_create_scan_timing_from_tics_siemens.m only includes the data from the first echo (ECHO = 0), but I wanted to confirm this.

Here is my batch file and an example subject of log files: batch_example.txt subject_Info.log subject_PULS.log subject_RESP.log

Thanks for any help you can provide!

[mrikasper]

Dear Liz,

Thank you for trying out PhysIO. Could you try to see what happens if you set the number of slices back to 84 (i.e., disregard the MB factor)? This might be a bug that we recently discovered internally.

All the best, Lars

[ejrise]

Hi Lars,

Thanks for your quick response! When I set the slices to 84, the code works and I get the following:

physio_out.zip

Even though it works, I'm not sure if the outputted regressors are correct due to the multiband acquisition.

Two more questions:

1. Do the cardiac pulse triggers (seen in the "bands" in figs 1,2, and 4) affect the regressor output at all? In Fig. 4, I see markers for cardiac R-peak (heartbeat) events only during the triggers, but those triggers aren't present throughout the whole cardiac time series. I'm not sure exactly why the trigger is set up this way as I didn't set up this part of the sequence.

2. This participant has many respiration waves whose peaks are cut off due to a too-tight respiration belt (you can see in the histogram in Fig. 12). However, the program doesn't seem to be censoring those sections of the data (Fig. 14). Is there a setting I can adjust to censor the sections where the peaks are cut off?

Thanks again for your help!

[mrikasper]

Dear Liz,

My apologies for the delayed reply, please see my thoughts inline below:

Thanks for your quick response! When I set the slices to 84, the code works and I get the following:

physio_out.zip

Even though it works, I'm not sure if the outputted regressors are correct due to the multiband acquisition.

• In general, I think you should be fine unless you do something very timing-critical with the regressors.
• Basically, you can adjust scan_timing.sqpar.onset_slice to any of the 84/4=21 slice excitation events within the TR. PhysIO assumes that slice 1 was acquired at time point 0 within the TR, slice 2 at TR/84, slice 3 at TR*(2/84) and so forth.
• In reality, 4 slices are acquired at 0, 4 at TR(4/84), 4 other ones at TR(8/84) and so forth. So, if you know which slice was acquired when within in the TR, you can choose that time point for the onset slice.
• If you are not sure, I would just choose the centre of the TR interval, i.e., 84/2=42. Sorry that this slice timing selection is not automated at this point.
• If you want to play around with multiple time points, you can also choose a vector scan_timing.sqpar.onset_slice = [0:4:84] to create a design matrix for every MB excitation time point during a TR and compare the results. I don't expect them to change drastically at your TR, in particular for respitory effects.

Two more questions:

1. Do the cardiac pulse triggers (seen in the "bands" in figs 1,2, and 4) affect the regressor output at all? In Fig. 4, I see markers for cardiac R-peak (heartbeat) events only during the triggers, but those triggers aren't present throughout the whole cardiac time series. I'm not sure exactly why the trigger is set up this way as I didn't set up this part of the sequence.

• These triggers are just proposed trigger events by the Siemens system, but not actually used for triggering, if you have not specified this in the sequence.
• PhysIO will also not use these triggers, unless you specify load_from_logfile for the initial cardiac peak detection.
• In general, the peak detection works better with PhysIO, because we can use the whole cardiac timeseries, whereas Siemens has to make a prospective decision (without seeing the future) for each pulse wave whether a trigger event (local min/max) occurred.

2. This participant has many respiration waves whose peaks are cut off due to a too-tight respiration belt (you can see in the histogram in Fig. 12). However, the program doesn't seem to be censoring those sections of the data (Fig. 14). Is there a setting I can adjust to censor the sections where the peaks are cut off?

• Yes, the clipping of the breathing belt amplitude is suboptimal, as these periods will appear as a period of constant max or min breathing phase for RETROICOR, and also respiratory volume per time will be underestimated.
• Censoring can be enabled by setting model.censor_unreliable_recording_intervals = true;
• This should be on by default, and it looks like it was performed in you physio.mat file.
• The censoring is only performed after the model estimation, and only for RETROICOR, i.e., you will only see it in the respective columns of the output regressor matrix R.
• From the looks of it, this is exactly what is happening, see the following zoomed plot of the respiratory regressors, which have occasional occurences of zeros:

• This is only a partial fix, of course, but you can check the F-contrasts of the physiological regressors (e.g., via tapas_physio_report_contrasts) to see whether the respiratory regressors still explain meaningful variance despite the censoring.

I hope this helps!

All the best, Lars