alexpreynolds
commented
7 years ago Thanks, looks like a bug.
I added a helper script to test called generate-random-sequences.py that generates a FASTA file with n sequences, each of specified length. Testing files with 1M-long sequences seems to yield IO problems:
$ ./generate-random-sequences.py 5 1000000 > /tmp/test.fa
$ ../kmer-counter --fasta --k=2 /tmp/test.fa
bash: [27709: 2] tcsetattr: Inappropriate ioctl for device
Segmentation fault: 11So I'll review how I'm reading in lines and see if I need to make some adjustments there.
This counts a kmer instance in forward and reverse orientation. If there's a hit for TCA, for example, there will be a hit for TGA, the reverse-complement of TCA — and vice versa.
Perhaps there is already established convention for defining which is unique, but I think an issue with collapsing is that, while it would shrink the output, I would need to pick one or the other kmer to collapse to.
arivers
It's great to see that Kmer-counter solves the problem of counting 1 kmer frequency per sequence in multisequence fasta.
I encountered a problem running two long sequences (4M bp and 2M bp) through it.
using the following command: mer-counter --fasta --k 4 ~/Downloads/2seqs.fasta > kmercountertest.txt
It generates 41198 kmer profile lines instead of 2.
I also wondered if it takes into account reverse complementarity. For example if k=4 we would have 256 unique kmers but with since we cannot tell if we sequenced the forward or reverse strand we collapse AAAA and TTTT etc. into 137 unique kmers.