Closed jingwei-li closed 8 months ago
thanks @jingwei-li for catching this!
There are some participants for whom we are missing files, due to an issue with the upload process itself. It is possible that these files are part of that list, which we are in the process of updating with the NDA. I will need to check with @perronea to confirm. I'm tagging him in so he can reply :)
I would rely on the executive summary and the motion files to ascertain data quality. You are correct that the MNI-bold represents an earlier stage in this process -- and in fact these files can be reproduced via use of our ABCD-BIDS pipeline and filemapper tools.
I found another data problem:
For sub-NDARINVX5TLCB96
rest run-2, the length of the MNI space file sub-NDARINVX5TLCB96_ses-baselineYear1Arm1_task-rest_run-2_space-MNI_bold.nii.gz
is much shorter (243 frames) than normal (i.e. in the dtseries
and motion tsv
files: 380 frames). Can you please also look into this problem?
@jingwei-li we uploaded the volumetric data for run-3 and run-4 for all subjects separately over a year ago. The NDA didn't get around to sharing that data until a couple months ago, however it should all be there. I suspect that when you downloaded the dataset originally it was before those extra runs got released. I would try to re-download specifically the data subset derivatives.func.runs_task-rest_volume
. If you're still having issues or you downloaded this data within the last 2 months let me know.
As to your other issue, thank you for bringing this to my attention. I'll look into this and let you know what I find.
Thanks! I will ask for the help from my colleague who is in charge of data management to download them again.
For the second issue, today I found another subject sub-NDARINVVVJJGU7V
run-1 with the same problem. So after you figure out what caused the problem, could you please perhaps also check for every subject? Thanks!
@perronea Hi! The first problem in this issue is resolved also for our side. But so far I haven't received any info on the second problem I raised (i.e. inconsistent lengths between space-MNI_bold.nii.gz
and dtseries
files of the same run). May I now the current situation of your further investigation?
@jingwei-li Thank you for resurfacing this issue. We've noted the problem and have been working on uploading a patch to the year 1 data with all of the necessary corrections. I have just been a little sidetracked with updating some of the utilities and pipelines. I'll update you here when that data is uploaded to the NDA.
Hi @jingwei-li, we are still working on updating the data available on the NDA and you can check the ABCC ReadTheDocs release notes for updates on this. It may be some time before these subjects are updated, so I would exclude them from your analyses for now. Thank you!
Hi, I'm working on the preprocessed resting-state fMRI data in the ABCC release. I found that for some runs, the preprocessed files in surface fsLR32k space exist, but the corresponding MNI space files don't, e.g. for the subject
sub-XXXXXXXXXXXX
, runs 3 & 4. Here list all the resting-state files of this subject:You can see that
run-1
andrun-2
have both_bold_timeseries.dtseries.nii
and_space-MNI_bold.nii.gz
files, butrun-3
andrun-4
only have_bold_timeseries.dtseries.nii
file. I was thinking if it was due to high motion in runs 3 and 4. Indeed, mean FD of run 4 is much higher than run 1. However, from what I understand from your preprocessing description, projection to surface space only happened after fMRIvolume pipeline, which means motion censoring has already been done. So high motion doesn't explain why fsLR32k space files can exist without the existence of MNI space files.What would be the reason of this discrepancy? Should I still trust the quality of the runs without MNI space timeseries, even if the surface files exist? Thanks in advance!