Closed cumbof closed 2 years ago
Hello,
I think you are facing the same issue. By default, the number of threads is the maximum available so you can try -t 1
.
However, it seems that you use the k-mer rescue (--soft-min 3 --share-min 1
) which is designed for error handling in the context of indexing reads. Since your inputs are genomes, maybe you do not need this feature. In index mode, the only purpose of the merge is the k-mer rescue so you can probably skip it:
kmtricks pipeline --file ./genomes.fof --run-dir ./index --kmer-size 31 --mode hash:bft:bin --hard-min 2 --bloom-size 10000 --bf-format howdesbt --cpr --skip-merge
Téo
To be sure I did a test with about 1000 genomes using your command. I confirm that it doesn't work with a limit of 1024 (the default on most desktop systems). On my side, -t 1
and --skip-merge
both work.
Téo
Awesome, thanks for you help @tlemane!
I missed something else. Still because you have genomes, I think you should use --hard-min 1
to index all k-mers.
It makes sense. Thanks!
Hello, I'm struggling with the following problem:
I'm running
kmtricks
(installed throughconda
) in order to index 1051 genomes. This is the command line that produced the error:kmtricks pipeline --file ./genomes.fof --run-dir ./index --kmer-size 31 --mode hash:bft:bin --hard-min 2 --soft-min 3 --share-min 1 --bloom-size 10000 --bf-format howdesbt --cpr
And this is the error message (the backtrace log file is empty):
I'm not sure if this is the same problem reported in issue #15, this is why I'm opening this new issue. In case this is the same kind of problem, is there something else I could try to overcome this issue without increasing the the maximum number of open files (
ulimit
)?In #15 @tlemane suggested to also reduce the number of threads, but I didn't specify the
-t
argument, so this is not really useful in my case.Thanks in advance for your help