Tedana keeps repeating ICA due to "no BOLD components" in 7T resting state data

1

Hello all,

I have been attempting to use Tedana on multi echo 7T resting state fMRI data from a Siemens Magnetom Terra. The only preprocessing applied to it was motion correction with FSL mcflirt (same correction parameters applied to all 3 echoes). The scans are whole brain, 2mm voxels, TR = 2, multiband acceleration = 7, iPat = on.

I tried the previous suggestion of changing the seed value multiple times but it hasn’t helped.

The command that I enter is formatted like this:
tedana -d e1.nii.gz e2.nii.gz e3.nii.gz -e 16.2 40.8 124.08 --seed 3000 --tedpca kundu --verbose --debug

Then, it shows the following:
DEBUG tedana:tedana_workflow:491 Resulting data shape: (645120, 3, 300)
INFO tedana:tedana_workflow:577 Computing EPI mask from first echo
WARNING utils:make_adaptive_mask:110 5346 voxels in user-defined mask do not have good signal. Removing voxels from mask.
DEBUG tedana:tedana_workflow:592 Retaining 198975/645120 samples for denoising
DEBUG tedana:tedana_workflow:606 Retaining 111495/645120 samples for classification
INFO tedana:tedana_workflow:609 Computing T2* map
DEBUG decay:fit_decay:404 Setting cap on T2* map at 2663.91248
DEBUG tedana:tedana_workflow:617 Setting cap on T2* map at 0.26881s
INFO combine:make_optcom:242 Optimally combining data with voxel-wise T2* estimates
INFO tedana:tedana_workflow:634 Writing optimally combined data set: /Users/erizor1/Gdrive/Documents/grafton_lab/asap/asap_pilot_7T/evan_multiecho/ptx_scans/grappa_epis_mc_155/desc-optcom_bold.nii.gz
INFO pca:tedpca:229 Computing PCA of optimally combined multi-echo data with selection criteria: kundu
INFO collect:generate_metrics:123 Calculating weight maps
INFO collect:generate_metrics:132 Calculating parameter estimate maps for optimally combined data
INFO collect:generate_metrics:145 Calculating z-statistic maps
INFO collect:generate_metrics:155 Calculating F-statistic maps
INFO collect:generate_metrics:165 Thresholding z-statistic maps
INFO collect:generate_metrics:172 Calculating T2* F-statistic maps
INFO collect:generate_metrics:179 Calculating S0 F-statistic maps
INFO collect:generate_metrics:187 Counting significant voxels in T2* F-statistic maps
INFO collect:generate_metrics:193 Counting significant voxels in S0 F-statistic maps
INFO collect:generate_metrics:200 Thresholding optimal combination beta maps to match T2* F-statistic maps
INFO collect:generate_metrics:206 Thresholding optimal combination beta maps to match S0 F-statistic maps
INFO collect:generate_metrics:213 Calculating kappa and rho
INFO collect:generate_metrics:222 Calculating variance explained
INFO collect:generate_metrics:228 Calculating normalized variance explained
INFO collect:generate_metrics:236 Calculating DSI between thresholded T2* F-statistic and optimal combination beta maps
INFO collect:generate_metrics:247 Calculating DSI between thresholded S0 F-statistic and optimal combination beta maps
/opt/anaconda3/lib/python3.7/site-packages/tedana/utils.py:211: RuntimeWarning: invalid value encountered in true_divide
dsi = (2.0 * intersection.sum(axis=axis)) / arr_sum
INFO collect:generate_metrics:257 Calculating signal-noise t-statistics
INFO collect:generate_metrics:295 Counting significant noise voxels from z-statistic maps
INFO collect:generate_metrics:306 Calculating decision table score
INFO tedpca:kundu_tedpca:50 Performing PCA component selection with Kundu decision tree
INFO tedpca:kundu_tedpca:128 Selected 261 components with Kappa threshold: 8.76, Rho threshold: 24.25
INFO ica:tedica:85 ICA with random seed 3000 converged in 135 iterations
INFO tedana:tedana_workflow:671 Making second component selection guess from ICA results
INFO collect:generate_metrics:123 Calculating weight maps
INFO collect:generate_metrics:132 Calculating parameter estimate maps for optimally combined data
INFO collect:generate_metrics:145 Calculating z-statistic maps
INFO collect:generate_metrics:155 Calculating F-statistic maps
INFO collect:generate_metrics:165 Thresholding z-statistic maps
INFO collect:generate_metrics:172 Calculating T2* F-statistic maps
INFO collect:generate_metrics:179 Calculating S0 F-statistic maps
INFO collect:generate_metrics:187 Counting significant voxels in T2* F-statistic maps
INFO collect:generate_metrics:193 Counting significant voxels in S0 F-statistic maps
INFO collect:generate_metrics:200 Thresholding optimal combination beta maps to match T2* F-statistic maps
INFO collect:generate_metrics:206 Thresholding optimal combination beta maps to match S0 F-statistic maps
INFO collect:generate_metrics:213 Calculating kappa and rho
INFO collect:generate_metrics:222 Calculating variance explained
INFO collect:generate_metrics:228 Calculating normalized variance explained
INFO collect:generate_metrics:236 Calculating DSI between thresholded T2* F-statistic and optimal combination beta maps
/opt/anaconda3/lib/python3.7/site-packages/tedana/utils.py:211: RuntimeWarning: invalid value encountered in true_divide
dsi = (2.0 * intersection.sum(axis=axis)) / arr_sum
INFO collect:generate_metrics:247 Calculating DSI between thresholded S0 F-statistic and optimal combination beta maps
INFO collect:generate_metrics:257 Calculating signal-noise t-statistics
INFO collect:generate_metrics:295 Counting significant noise voxels from z-statistic maps
INFO collect:generate_metrics:306 Calculating decision table score
INFO tedica:kundu_selection_v2:138 Performing ICA component selection with Kundu decision tree v2.5
/opt/anaconda3/lib/python3.7/site-packages/tedana/selection/_utils.py:112: RuntimeWarning: invalid value encountered in true_divide
b_hat = np.reshape(b / np.sqrt((b**2).sum()), (2, 1))
WARNING tedica:kundu_selection_v2:287 Too few BOLD-like components detected. Ignoring all remaining.
WARNING tedana:tedana_workflow:699 No BOLD components found. Re-attempting ICA.

After this, it re-attempts the ICA over and over again without resolving. Is it possible that the echo times are too long?

My data and report files are located at shared_with_neurostar – Google Drive for viewing and download. It never gets to the point of creating the html report.

Thanks so much for your help!

2

Hi Elizabeth,

There are several reasons this can happen and the problem might be with the method. I’m currently downloading your data to take a closer look.
That said, I see one thing in your command call that looks a bit off. You list your echo times as “16.2 40.8 124.08” Generally the echo times are evenly spaced, particularly with the standard multi-echo pulse sequences I know of on Siemens scanners. You have a 24ms gap between the first two echoes and then an 84ms gap between the second two echoes. That’s really unusual. Is there any chance this numbers are not correct? Additionally, the signal decays with echo time a lot faster at 7T. I’d expect signifiant dropout even by 40ms and almost no remaining signal by 124ms. If these are the correct echo times, the later echoes might be too noisy to give a stable signal, which could explain the trouble finding T2* components.

Hope this helps

Dan

1 Like
3

I just looked at a few voxels in your data_pre_tedana. I see:

echo1   echo2   echo3
9712    3930    2400
9479    4440    1646
10664   4020    1456
6902    3561     2079

If you look at how values should decay across echo time (for example, for 7T the blue line at: https://www.researchgate.net/figure/Signal-decay-curves-for-different-T-2-relaxation-value-At-7-T-the-T-2-relaxation_fig13_321579361 ) I’d except your values at echo2 (40ms) to be about 1/5 of the value at echo1 (16ms). Your values at 124ms would be close to zero. That’s not what I’m seeing, which makes me think you aren’t inputting the correct echo times.

I looked in ep2d_bold_2mm_iso_p2_sms7_HCP_AP_CMRR_3TE_ep2d_bold_2mm_iso_p2_sms7_HCP_AP_CMRR_3TE…_e3.json and I see: "EchoTime": 0.0654, You should double-check, but if that’s correct, your third echo should be 65.4ms. The other two json files match your 16.2 and 40.8ms TEs.

Best

Dan

2 Likes
4

Hi Dan,

Thanks so much for your help! You are correct - I was accidentally inputting the echo time 3 incorrectly. However, I re-ran Tedana with the correct echo times (16, 41, 65) and it is still having the same issue. I looked at desc-optcomPCAReduced_bold.nii.gz and found that huge chunks of the data are being removed by the good signal masking, which you can see in desc-adaptiveGoodSignal_mask.nii.gz. Is there a way to modify Tedana so that it is less conservative with the masking, or is this scan a lost cause due to poor signal?

I’ve updated the Google folder to have the newest Tedana outputs with the correct echo times.

Thanks,
Liz

5

I’ve take a look at the data - and I have a few concerns. The sequence parameters seem very strange - 2mm voxels and a 2s TR don’t seem to match up to the 7X multiband, 2X GRAPPA - why so much acceleration? That high level of acceleration is leading to extraordinarily poor data quality, due to aliasing.

A 60ms 3rd echo time seems a little long to me, perhaps a 3 multiband, 3x GRAPPA approach with shorter echo times would give you much better signal with much less overall acceleration?

It looks like a multichannel transmit coil, so perhaps the flip angle is correct but 45 degrees would be low for the Ernst angle estimate at 7T with a 2 seconds TR.

it seems that the noNaN data the data to be input into tedana? Perhaps I am wrong, but it looks like there is still motion present there which wouldn’t help things. Additionally, with a 2s TR you would probably want to apply slice timing to these images.

The desc-optcom_bold.nii.gz may be a better file to look at - thats is your data after optimal combination and it seems that the masking isn’t removing too much data there. But masking is needed to deal with the signal dropout at your later echoes (which is exacerbated by the levels of aliasing + thermal noise amplification).

That said, you can provide your own mask on the command line to tedana with --mask YourMaskFile.nii.gz. I used AFNI to generate an Automask of the data and ran it with default settings (did not use kundu option) and it generated reports and has some things that look like networks. I tend to actually prefer to the kundu option, but perhaps it isn’t a good match here. I’m not certain. In any case, it may be worth running with your own mask to see if that helps.

In my opinion this sequence needs to go back to the drawing board - though perhaps I am missing some important detail. I’ve uploaded a pdf of a test sequence (to the folder you shared) I made that may be useful as a better starting place. I can’t say that it is what you should use, as I have not tested it extensively, but it gives better parameters with less acceleration.

2 Likes
6

I haven’t had a chance to look into this more yet, but do you know what version of tedana you used? We made some changes about a year ago that would have maintained more voxels within the mask. The updated version is tedana --version == 0.0.12

Dan

1 Like