I’ve just discovered RICA as a tool for manual classification of components. It seems extremely simple and easy to use but I’m confused as to how it works in terms of actually having an impact on the functional file itself.
Do I need to rerun Tedana after saving the ‘manual_classification.tsv’ file that RICA generates? Obviously, the functional files I have denoised through using Tedana have not been impacted by the manual classification at all but I’m not sure how to have them update with the new components. Any information on how this works would be very useful!
I suspected as such and tried doing this but I received the following error before Tedana terminates:
File "C:\Users\CulhamLabTR\miniconda3\lib\site-packages\tedana\workflows\tedana.py", line 510, in tedana_workflow
shutil.copyfile(ctab, op.join(io_generator.out_dir, op.basename(ctab)))
File "C:\Users\CulhamLabTR\miniconda3\lib\shutil.py", line 244, in copyfile
raise SameFileError("{!r} and {!r} are the same file".format(src, dst))
shutil.SameFileError: 'F:\\ED_Pacman\\tedana_kundu-stabilize\\sub-02\\run01_play\\manual_classification_rename.tsv' and 'F:\\ED_Pacman\\tedana_kundu-stabilize\\sub-02\\run01_play\\manual_classification_rename.tsv' are the same file
I am using the manual classification file as the --ctab input and the ICA_mixing.tsv as the --mix. Any idea what’s causing this error? Thanks again for the fast reply!
The easiest workaround I can think of right now is that you rename the file to ica_metrics.tsv. You might want to save a copy of the original file just in case though. I believe this workaround should work because tedana will only attempt to copy the file when the --ctab file is not named ica_metrics.tsv.
Nevertheless, I will try to replicate the error with some other data.
I’ve tried the workaround but, unfortunately, I am getting the same error:
shutil.SameFileError: ‘F:\ED_Pacman\tedana_kundu-stabilize\sub-02\run01_play\ica_metrics.tsv’ and ‘F:\ED_Pacman\tedana_kundu-stabilize\sub-02\run01_play\ica_metrics.tsv’ are the same file
Let me know if you come up with anything on your end and the error replicates. Thanks again for looking into it!
I believe the problem is that you’re using the input folder as the output folder. Tedana tries to copy over reused files from their original location to your current run’s output directory. Until recently, tedana would just skip over that step when users re-ran the workflow on the same folder, but we overhauled the way tedana writes out files in version 0.0.11, and I don’t think we accounted for this particular case when we did that.
We will definitely fix things on tedana’s side for 0.0.12, but in the meantime I think the best solution would be to change the output directory when you switch from the automated decision tree to manual classification.
I just wanted to follow up on this. I’ve found that putting the manual classification into a different folder helps with the error but rerunning it with the code above (having changed the output folder) seems to have no effect. The only way I can modify the accepted components is by including the --manacc command and individually listing each component to accept (which, I believe, was what RICA is supposed to replace).
Apologies if I’m asking obvious questions (I’m new at this) but how can I use the manual_classification folder from RICA to overwrite the list of components to accept/reject? Is the --manacc command necessary somehow? Thanks again!
I was convinced the manacc options wasn’t necessary. Actually, if you look at lines #L739-L742, manacc will only overwrite the component table you pass with ctab. You should pass Rica’s tsv table as ctab for this to work.
We should add something about Rica in the docs though. I will open an issue now.
Edit: Here’s the GitHub issue to update the docs. Could you please confirm that passing Rica’s manual_classification.tsv file as --ctab works as expected? Thanks!
All of the files are generated in the new output folder (as expected) and, indeed, the manual_classification.tsv file is generated there reflecting the correct component classification. The tedana_report.html, however, is still reflecting the original components so it is unclear whether the optcomDenoised file is using the original classifications or is updated using the manual_clasification.tsv.
@Davies given that this topic has been resolved and hasn’t been updated for 2 years, I think your question merits a new topic. Would you mind opening a new topic with the Software Support template?