ME processing: Multiple runs with varying lengths error

AFNI Message Board
1

AFNI version info (afni -ver): Version AFNI_25.0.02 'Severus Alexander'

I am getting the following error when running a script similar to Example 13:

#-- applying input view as +orig
#-- template = 'MNI152_2009_template_SSW.nii.gz', exists = 1
#-- have APQC atlas APQC_atlas_MNI_2009c_asym.nii.gz
#-- will use min outlier volume as motion base
#-- including default: -find_var_line_blocks tcat
#run 3 reps vary between echo 1 and echo 3

Here is my script:

afni_proc.py                                                         \
            -subj_id                   {$subj}.OC_011425                      \
            -blocks                    despike tshift align tlrc volreg mask combine surf blur scale regress     \
            -radial_correlate_blocks   tcat volreg                           \
            -blip_forward_dset         {$subj}_fMRIFieldMap_AP_6.nii         \
            -blip_reverse_dset         {$subj}_fMRIFieldMap_PA_7.nii           \
            -copy_anat                 $SSW_dir/anatSS.{$subj}.nii                       \
            -anat_follower_ROI         FSvent epi $anat_dir/fs_ap_latvent.nii.gz       \
            -anat_follower_erode       FSvent                                \
            -regress_ROI_PC            FSvent 3                              \
            -regress_ROI_PC_per_run    FSvent                                \
            -regress_make_corr_vols    FSvent                                \
            -dsets_me_run           	 {$subj}_cmrr_mbep2d_bold_MEMB6_REST_8_e*.nii \
            -dsets_me_run			 {$subj}_cmrr_mbep2d_bold_MEMB6_REST_11_e*.nii \
            -dsets_me_run			 {$subj}_cmrr_mbep2d_bold_MEMB6_REST_14_e*.nii \
            -echo_times                13 30.99 48.98 66.97 84.96            \
            -reg_echo					2									 \
            -combine_method            OC                                    \
            -tcat_remove_first_trs     0                                     \
            -tshift_interp             -wsinc9                               \
            -mask_epi_anat             yes                                   \
            -align_unifize_epi         local                                 \
            -align_opts_aea            -cost lpc+ZZ                          \
                                       -giant_move                           \
            -tlrc_base MNI152_2009_template_SSW.nii.gz                 \
        	-tlrc_NL_warp                                              \
       		-tlrc_NL_warped_dsets                                      \
        	 $SSW_dir/anatQQ.{$subj}.nii                			   \
        	 $SSW_dir/anatQQ.{$subj}.aff12.1D            			   \
       		 $SSW_dir/anatQQ.{$subj}_WARP.nii			 			   \
            -volreg_align_to           MIN_OUTLIER                           \
            -volreg_align_e2a                                                \
            -volreg_tlrc_warp                                         		 \
            -volreg_post_vr_allin      yes                                   \
            -volreg_pvra_base_index    MIN_OUTLIER                           \
            -volreg_warp_final_interp  wsinc5                                \
            -surf_anat                 $anat_dir/{$subj}_SurfVol.nii      \
            -surf_spec                 $anat_dir/std.141.{$subj}_?h.spec  \
            -blur_size                 6                                     \
            -regress_censor_motion     0.2                                   \
            -regress_censor_outliers   0.05                                  \
            -regress_motion_per_run                                          \
            -regress_apply_mot_types   demean deriv                          \
            -html_review_style         pythonic						 		 \
            -execute

** failed command (create_script):

code text  # or delete if not needed
2

This is usually caused by the scanner being stopped manually. The result is that one echo won't have the same number of TRs written to the file. You can quickly check this with:

3dinfo -prefix -nt {$subj}_cmrr_mbep2d_bold_MEMB6_REST_*_e*.nii

That should return a list of all of the time point counts for each multi-echo run.

To also ask the other curious question: you have five echos, but are using the built in optimally combined function. Do you also plan to use tedana later?

3

This is helpful, thank you.
Is there a way to use the shorter run? Or will I have to process separately?

Yes, we plan to use tedana later. Our analysis computers do not have enough RAM to handle tedana processing (unfortunately). If you have any recommendations for computers that can handle tedana, please let me know!

4

Howdy-

If you have runs of length 99, 99 and 97, say, then prior to running AP you might want to trim down the first two to match the length of the third. You could do this with subbrick selectors, like this (NB: AFNI, like Python and C, is zero-based counting in indices):

3dTcat -prefix DSET_SHORT DSET_LONG"[0..96]"

Also, on a separate note, I was wondering if the variables in the top script that are written like {$subj} would be more standardly written as ${subj}? I'm used to seeing the latter in shell scripts of different kinds. I think in either case, the variable name is protected to expanding "too far" via a neighboring "_" character, but the ${variable} is more familiar to me.

--pt

5

Hi Paul,

Thank you for your feedback!

We are using FIRMM to capture real-time motion and data quality for our resting-state scans. The 3rd run is typically shorter due to hitting our threshold of 15 min of "quality time" without motion (over .2mm). I wouldn't want to trim the first two runs because I'd be losing "quality" data.
Should I scrap the 3rd run all together? I've been thinking yes...

Noted! I will implement this change. I appreciate you!

6

Hi-

I'm a little confused. I thought within the 3rd run, it was just a matter of different echoes had different numbers of volumes---presumably a small difference, and so a little trimming of one or two echos could solve the issue. I don't think it matters if run-01 and run-02 have different numbers of volumes, but for a given run, all echo datasets need the same number of volumes.

What is the output of:

3dinfo -nv -tr -prefix ${subj}_cmrr_mbep2d_bold_MEMB6_REST_14_e*.nii

?

Sorry if I am misunderstanding, though, which is certainly possible. It's a Friday afternoon, afterall.

--pt

7

I believe I am the one misunderstanding.

Here's my output:
213 1.355000 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e1.nii
213 1.355000 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e2.nii
212 1.355000 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e3.nii
212 1.355000 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e4.nii
212 1.355000 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e5.nii

8

Cool, thanks. That run has 5 echo dsets. To me, this seems like what happened is that the veeery last volume didn't get fully aquired for some of the echoes---e3, e4 and e5 are missing the last time point. So, rather than throw out all of that run's worth of data, just trim down the e1 and e2 dsets to be of length 212, removing 1 time point at the end, like this (or use move the "input" dsets to a temporary name, and then have the output name here just replace them "in place", for easier scripting):

3dTcat \
    -prefix 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e1_TRIM.nii \
    1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e1.nii"[0..211]"

3dTcat \
    -prefix 1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e2_TRIM.nii \
    1013_T1_cmrr_mbep2d_bold_MEMB6_REST_14_e2.nii"[0..211]"

How does that seem?

--pt

9

Seems reasonable! I'll add this to our workflow.
Thank you!