Open atcg opened 9 years ago
This looks like a bug in the way that I handle finishing a target in this weird special case. That target should not have continued to iteration 3. I will try to reproduce it with some test data and see if I can figure out why ARC is doing this. Thanks for the bug report.
Thanks Sam. It's possible it has something to do with the assembly being killed at the end of the iteration, while ARC is just waiting for the last assemblies to finish. I've noticed when that happens, spades keeps running in the background to finish the assembly (even after ARC has given up on it and proceeds to start dumping the contigs for the next iteration).
I'm not sure that is the case for that particular target that got the keyerror, though.
I have just come across this problem as well. The following may or may not be relevant: a previous run with the same read set and the same reference finished successfully and had sloppymapping=False. The run that crashed had this parameter set to True.
Beate
I'm running into an issue where I get a python KeyError for targets that fulfill the following conditions:
1). Target assembly fails in iteration 1. Then "Writing reads as contigs." 2). Target assembly killed (spades times out) on iteration 2. Then "Writing contigs from previous iteration." 3). Target recruits fewer reads in iteration 3 than in 2. Target assembly fails in iteration 3.
Bottom of the ARC output:
Any thoughts? Thanks very much! Evan