No BOLD components detected error

[cjl2007]

Hi – I am attempting to run Tedana v24.0.2 on EPTI data (https://martinos.org/~fw089/publications.html; 122 TEs, spanning 4.405 ms to 63.695 ms, 3mm isotropic voxels, TR = 1.7 seconds, MB factor = 2, ~15 minutes total). When I view the raw data, there are no obvious artifacts or indications that something went wrong with the acquisition, looks good

Hoewever, Tedana fails to classify any of the components as BOLD-like, despite there being obvious signals of interest (see an example below; by the way, Tedana interpreted the TR in the header file as 1700 seconds, not 1700 milliseconds, which is why the FFT and time axis looks so strange, I have since changed the TR in the headers to be 1.7, which solved that issue).

WARNING tedana:tedana_workflow:834 No BOLD components found, but maximum number of restarts reached.
WARNING tedana:tedana_workflow:913 No BOLD components detected! Please check data and results!

One other thing to note is that in the course of my troubleshooting, I found that if I use 3 TEs only (the first, middle, and last TE), Tedana performs as expected, the signal classifications look fine,

Does anyone have any ideas about what might be the issue here, or suggestions for things to troubleshoot when encountering this particular error? I can share the data if it would be helpful,

Thank you!
Chuck

[CesarCaballeroGaudes]

Hi Charles (@cjl2007), let me suggest that it would be nice to see the slope of the kappa & rho parameters. As far as this component is concerned, the kappa value is much larger than rho. Therefore, it is likely BOLD. Btw, thanks for testing EPTI. Looking forward to hearing your opinion about this promising sequence.

[cjl2007]

Hi Cesar (@CesarCaballeroGaudes) --- Thank you for the quick response. I pasted a screenshot of the kappa and rho value distributions below, definitely looks different... not the usual "L" shape in the kappa vs. rho scatter I like to see, and the Rho Rank has this weird sigmoid like look to it that is not typical, right?

[CesarCaballeroGaudes]

Hi @cjl2007, thanks for the kappa & rho plot. The fact that no components where labelled as BOLD related is what I find most surprising. There are some components with a very high kappa and low rho that should have been accepted according to the TE-dependent principles. My intuition makes me think that the elbow for the kappa curve should not be the one computed, but in the elbow in the kappa around 40 instead. In addition, can you share the command? or more specifically, which decision tree are you using?

[eurunuela]

In addition, can you share the command? or more specifically, which decision tree are you using?

You can find the command at the bottom of the html report.

[cjl2007]

I have tried a variety of options, different decision trees, different pca options, with / without explicit mask, etc.

Here is an example command,

tedana -d /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E001_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E002_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E003_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E004_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E005_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E006_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E007_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E008_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E009_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E010_acpc.nii.gz /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Rest_E011_acpc.nii.gz -e 7.1 12.98 18.86 24.74 30.62 36.5 42.38 48.26 54.14 60.02 63.45 --out-dir /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/Tedana/ --tedpca kundu --fittype curvefit --mask /home/charleslynch/Desktop/ME06/func/rest/session_1/run_1/brain_mask.nii.gz --maxit 500 --maxrestart 5 --seed 42

Note: I am not running all 122 TEs in this case for the purposes of speeding up my debugging,

[handwerkerd]

I'll try to respond more later, but I wanted to tag @katielamar. She's working on exactly this with Tom Liu at UCSD. The one core known issue (which we still need to integrate into the main tedana) is that F stats are calculated for T2* and S0 fits as part of the calculations of kappa and rho. Since EPITI has many overlapping echoes but still only 3-4 independent degrees of freedom, this skews the F stats. The fix is to set the degrees of freedom in a way that not the total number of echoes.

[katielamar]

Hi, yeah we had the same issue. The DOF should be changed to the number of bases set in the EPTI reconstruction. The default is 3 or 4 for most of the EPTI scripts provided by MGH. Currently Tedana sets the DOF to the number of echoes (as Dan mentioned). Once we changed that, Tedana worked well with EPTI data (even with 122 echoes). Let me know if you have any further questions.

[tsalo]

Is the number of bases recorded in the DICOMs/BIDS sidecar at all?

[katielamar]

For EPTI, the number of bases is set in the recon script. I don’t think they make note of it in any of the recon outputs. For most of the 3T scripts it is set at line 110 except for the GESE (p3/p6) where it’s set at line 125.

[tsalo]

On tedana's end, we could maybe add a command-line argument to override the degrees of freedom (--n-independent-echos?).

From a dataset curation perspective, I think we should probably add a metadata field that indicates the number of bases to the BIDS specification. Optimally, fMRIPost-tedana will just infer that information from the sidecar.

[katielamar]

Yeah that would be great. I ended up cloning this repo and adding that flag myself so I can run it easily from the command line. Definitely, makes it easier to have the flag since I’m often comparing the EPTI results to ME-EPI where the number of echoes is the DOF.

[tsalo]

@handwerkerd we calculate the F-statistics for ascending numbers of echoes, based on the adaptive mask. Is there some link between the echo times used and the number of independent echoes that we can use for that? Something like a mapping between echo time and the base(s) it's derived from?

[cjl2007]

Ah, this all makes sense, thank you, @katielamar. I see bases variable definition (K = 3) in the recon Matlab code now.

This also explains why Tedana was performing as expected in my hands when I tried running it using 3 of the 122 TEs only.

@katielamar - If you have time and are willing to share, I would be interested in trying your modified version with the additional flag controlling the DOF.

[katielamar]

Sure. More than happy to share. Would you like to meet over a video call? I can also just send the code with a quick explanation of what I changed if that is easier. I'm a little busy over the next few days and I would need to clean my code up a bit before sending, but I could probably get that to you by next week.

[eurunuela]

@katielamar if you don't mind and feel comfortable with it, I think it would be very useful to have your changes in a pull request, so we can incorporate them to tedana at some point.

[handwerkerd]

Sorry for the delayed response from me. If @katielamar can also share your existing code with me or @eurunuela we can add it to the main tedana.

To @tsalo's Q, I agree there is a separate issue with adaptive mask. We only want to use a voxel with at least 3 good echoes for the ICA step. The trouble with this is that the first three echoes in EPITI are nearly identical data. We want to make sure the echoes are good up through the point where there's at least parts of 3 independent measurements. I haven't fully dug into EPITI reconstruction to figure out what the shortest number of echoes that sample from at least 3 bases (the math is fancier, but it's roughly a sliding window reconstruction). By just treating it like a sliding window, the conservative answer would be, for bases set=3, (2/3)*(total # of echoes)+1. I suspect the actual recon method would include info from all 3 bases at a shorter echo. The problem is, with 100 echoes going to >100ms, I doubt the first good echo is at last as 67ms. This might be overly conservative. I haven't personally worked with EPITI data yet. Maybe Katie knows more?

[handwerkerd]

I also agree it would be good to get the number of bases used for reconstruction either directly into the NIFTI header or into a BIDS JSON. This is an important parameter that would be nearly impossible to estimate post hoc, since the point point of multi-echo is that there is dependence across echoes, and we're trying to measure dependence between independent measurements.

As issue can be opened for BIDS here, but I'm slightly traumatized by my last attempt. https://github.com/bids-standard/bids-specification/issues The specification thoughts I have are:

• Should EPITI be it's own Pulse Sequence Type? It's not clear if there is a standard list of pulse sequence types for that key.
• In timing parameters add something like EPITIBasisSet that expects a number
• Overall, since each echo 4D volume has it's own JSON, I guess this means there are now ~100 JSON files that will be identical except for the EchoTime. This sounds like a mess, but I'm not sure how to fix it without higher-level changes in BIDS.

[katielamar]

Sure. I'm more than happy to share my code. @handwerkerd, I will reach out to you via email. I think before I share the code it needs be cleaned up a little bit. The way I had to pass the DOF variable into the calc_kappa_elbow and calc_rho_elbow functions was a bit hacky. I've occasionally run into bugs due to it and although I have a workaround myself, there is definitely a better way to do this. Let me get that cleaned up (maybe with some help from Dan) before I make a pull request.