Do you know what exactly caused the problem? Maybe it is worth testing it with metabat 2.15 in case you can reproduce the error (or at least open an issue, seems there were some fixes since 2.13)?

In general regarding metabat, wouldn't it make sense to run it using the parameter --seed 1 to avoid the usage of random seeds and ensure reproducibility?

Fair enough, I didn't explain very well. The problem doesn't appear to be reproducibility but rather that the output of jgi_summarize_bam_contig_depths in the process metabat can be shuffled when using multiple cores. This is a hypothesis and the problem only occurs sometimes, but it never occurred when I set cpu = 1, as detailed in #32 . I do not think that --seed 1 would help in this case, but I would be glad if I were wrong.

As to avoid running metabat on only one core, it is possible to split process metabat into two processes so that only jgi_summarize_bam_contig_depths runs with one core, that should solve the problem as well when my theory is right. Or we could use a conditional setup i.e. only when error an error exit status of 1 occurs then a retry with 1 core would be triggered. I would not know how to implement the latter and an error exit status of 1 is not specific at all to the problem.

What do you suggest?

Likely this doesn't solve the problem. There is a channel problem, which is not always reproducible. I am working on it.