paudano
commented
4 years ago Each assembly group is it's own Snakemake process, so SMRT-SV runs Snakemake again for each one, and each one has it's own lock directory. When you deleted the partial group, its Snakemake lock was also removed.
At our lab, these directories are deleted after each assembly group job completes or fails (SGE creates and removes the temp directory for each job), so the intermediate files and '.snakemake' directory in them are automatically removed. In your case, it's finding the group from before, which is not intended.
I think SMRT-SV should be checking for those assembly group directories and failing if they exist (potentially having an option to continue with them). It's possible that using a partial group might corrupt the results, although Snakemake should handle it correctly in most cases.
I'll be deploying some changes soon, and I'll see if I can improve this.
If my script fails because of walltime issues, the manual says I must removed the locks in the .snakemake directory. However, when I did only that, I received the following error for some of my assemblies that were left unfinished when my previous run abruptly ended -
Error: Directory cannot be locked. Please make sure that no other Snakemake process is trying to create the same files in the following directory: /ufrc/baer/s.ayush/SV_MA/Analysis/smrtsv2/N2/Strategy1/WS270/TEMPDIR/asm_group_gr-V-8000000-1000000 If you are sure that no other instances of snakemake are running on this directory, the remaining lock was likely caused by a kill signal or a power loss. It can be removed with the --unlock argument.
I've since realized that deleting the assembly directories (that were abruptly ended) in the Temporary folder solves it. I didn't find it on the forums here or on the manual, so I thought I should make a note of it.
Ayush