Luis Pedro Coelho
Luis Pedro Coelho
Unfortunately, there some issue with the action, so I am reopening here.
There was actually a long standing bug (more of a missing edge case) that somehow was only triggered on certain versions of Windows! (having to do with how many bits...
New version (1.4.17) is up on pypi!
This seems to be another instance of semibin not scaling well in terms of memory usage for very large binning jobs: https://github.com/BigDataBiology/SemiBin/issues/171
Those files are quite large (although, they seem a bit unbalanced, how the bam file is almost as large as the fasta file, is that correct?) If it is already...
If it is not consuming CPU, I think there is a weird bug here. Is this reproducible?
Are you talking about the `generate_sequence_features_multi` step? It should use multiple CPUs (threads) if available.
In the newer versions, we use pytorch files (using the extension `.pt`, which IIRC is the recommended one) and load in safe mode. We do try to reload in unsafe...
Is the separator `C` the same that the `concatenate.py` file uses? It's important that they be consistent
The contigs names also have the separator? That is normally not good (and the internal `SemiBin2 concatenate_fasta` command would have checked for that and errored out).