Closed jungheejung closed 3 months ago
@yarikoptic This is a scan where the DUP is longer (and expected size) compared to the BOLD data Based on the scannotes, the scanner rebooted. I wonder if this mismatch has to do with the scanner reboot?
Is there anything we can check to make sure the DUP is the correct file and that we need to salvage it? Maybe looking at the time acquired would help? or perhaps that's already the logic of Heudiconv. What do you think?
interesting case which might warrant changes or at least a warning in heudiconv and possibly adjusting our SOPs (standard operating procedures) and/or PACS configuration for whenever scanner is restarted or otherwise session is interrupted but then started "like anew" with the same accession.
TL;DR: as numbering of sequences was restarted upon restart new sequences with the same sequence number and name overwrote old ones. heudiconv
used sequence number and name to decide on dups -- their sequence. It doesn't use Time of any kind, and thus it incorrectly assigned __dup to the NEWER sequences with smaller sequence number.
@yarikoptic and I plan to use the rename_file
script to resolve these swapped dups.
should be "compatible" with datalad run
, so do via that -- it would help to record explicitly what was renamed from what
c0940dc881edf6c564dc40d0bbd0238a87aaa188 ./code/spacetop-prep/spacetop_prep/datalad/remove_dups_anatfmap.sh
TODO
task-social
is expected to have 872 TR, e.g. acquired scans./sub-0133/ses-04/func/sub-0133_ses-04_task-social_acq-mb8_run-01_bold.json
./sub-0133/ses-04/func/sub-0133_ses-04_task-social_acq-mb8_run-01_bold__dup-01.json
scannotes
PVC (task-social) run 01: full reboot - scanner did not boot.