fjdf/slamem

Finding Maximal Exact Matches (MEMs) using a Sampled LCP Array

slamem's Issues

Segmentatio fault trying to index human genome

Hi, using gcc 4.8.2 and after 24 hours I got a seg. fault

However in your paper you could index the human genome. I wonder which steps I have to make to reproduce your results.

Thanks in advance.

./slaMEM -m ~/genomes/human.fa ~/genomes/chimpanzee_genome.fa
[ slaMEM v0.7.1 ]

Loading sequences from file </genomes/human.fa> ... (3157590979 bytes)

01 [human ](-1199289884 bp) OK

Loading sequences from file </genomes/chimpanzee_genome.fa> ... (2678898688 bytes)

02 [gi|114573996|ref|NW_001229892.1|Ptr1_WGA](-1653809352 bp) OK

1 reference and 1 query successfully loaded
Using options: minimum MEM length = 50
Processing reference sequence "human" ...
Collecting LMS positions .......... (798090407) OK
Sorting LMS suffixes .......... OK
Induced Sorting suffixes .......... OK
Collecting LF samples .......... OK
Collecting SA samples .......... OK
:: FM-Index size = 3482 MB
Building Sampled LCP Array Segmentation fault (core dumped)

Not progressing

Using "slaMEM" to find MEMs in human reference genome hg19 (3.2 Gigabytes). I executed the following command:

./slaMEM -l 17 -b -n ../bio_data/gnome/hg19/slamem/hg19.fna query.fna

query.fna contains a single sequence of 3119 bases. The program is "Building Sampled LCP Array" and not progressing for the last 10 hours or so. The program is executing for nearly 24 hours now.

Fails on instances where no MEM is found

Thanks for this great piece of software!

I have one bug report and one request

1. slaMEM fails when no mems are found. See e.g., below instance
2. Could slaMEM output exit code 0 when called as slaMEM? It matters when testing builds with travis.

slaMEM -l 17 refs.fa  reads.fa -o outfolder/mems.txt

reads:

>read3
GTAATTACAGGACTTGTGGTTGGTTTTACGATAGCGACTGAACTGCCGAACTTTGTTTAATAATTACACGTTAATCTGGGACAAGCAAGCTGAAGACGCAGTAACAGTTGGTTCTTGCTGAAAGGACCAACCTATGACTTTCTGGTTTTGCCTGTTGTGAACAACGTTACAGTAAAAGGCGGCTTCGTGACTGCTGGTCGAAGAGCCAAATGGTCAACATTAGCATAGCTTGCTTCCTCTTTTTCGTTGCGGAGTTAGCAGGAGAACGTTATGTTTTTACCGAAGAAGGCGCAGTGTTTGCTTGACAATTTACCGTCGTGTCTTCGGTAACAGATATGCTTACCGCTATCCTAACCACCTCAATCACTGCCTTACGGACGTTAACCTAACGCAAATGCCACCAAATACATATGTAAGTCCTCTTAATGTTTGCATGCTTAATCTTTTGATTATTTCCTCTTTCTTTTCTATTTATTAATCCTGTGTCCTCGCCAACCGAATCAACATAAATACGTCAACGAATCAAATGTTGATCTCAAATATCTGTGTCCATGAAATTTCGATCGTAAAAACA
>read4
GGCCTCTAAATTCGGTATCAAGTATTTGCTTCTCCACCGCCAAGCGCACATAAATTCTTTGCGAGTGTTGTTTGGCCACTTTTGGTAGCTCCTGTTTCTTGGCAATTTTGGCTGACACGTTCAGTTTCTTTGCTCCAACTTCGTAAGCAGTTAGTGTAGGCGTGCGGAGGCGTGCGCTACTCGCTACATCGTTGGTTCTACCACCCATATGCCATGGCGTCCTGTAGGTTTGCGCCTAATTACTCGAAGCGCTTTCATTTCTACGAAACGTTTTGGAATAATGTCAACTTGGGCATTGTTGAAACTACGGCTTCCTTAATGCTGACAACCTTGTTTAGTTGTTGTTCTTCCCTTCTTCCAGCATTTAATAACCAGCTTGTTTTAACTCCTTCGCTTTTTCGACTTTCTCCTTCCAGCACCGCAACGTTCTTTTAAGCTACAACGCTTTCTTGAAATCTTCTCGTCATAAA

refs:

>1^1000^1484
AAAGTAATGCCTCTACGTCAGTCGGAACAATGTCGTCGTGTAACTCGACGATCTTAGGAGCTACTAAGGAGAGTCTGTAGGGAACCGACTGGGAAGGTGCCACAAGTTTTCTCTACTACTCCGTCTCCTAAAACAACTCCAAGTGGAAGGTCTGTGGGTTTTTGAGTATAGTCCGTATCTAGACCCAAAAGGGCTTACCTTCGCAATGAAAGAATATCCTTATAGACACGAACGGGAAGAACGGAATCGTTATTAATGACGTCGTACAACGTTTTCCAAGTTCTCCTCTTCCTCCGGATTCGGTTTGGGTTATCTCAACTAGTCCTTTCAAAGACATTGGAGAGTTTCACCTTCCCGTTAAGGTAGAACCCTCAGCATGTTTCACCCCCGGTGACCACTCAGTTACGGAATGTTTTTAAGCCACCTCAGCTAGTGTTCCGAGAGGTGACAGCGACGACGTCCACGTTTGGACTTGTTATCATAA
>1^6337^6813
CATCCTAACATGTTTAGGAACTTCCCCCGAACGTTCGACTCTGAGACACCCCAGGGACCGTACTCTAACTACCTACCTAGTACCCATAGAGAAGTCTTTTGACTTCCAGGCCCTACCACGAGAGGTCTAGTCGAACCTTTACAGGTACTAAAGGTATGTCTACTTTAACTTGTGGAACACCAACTTCTCAACCACTTCTTCTCCCTTCTCACAAACCTACGACATCTTTGATAGTAGTGTTGGTTCAGATATTCATCGTCTGCAGAGTCAGTAAAGTCCTTTGACCAAGGACCCAAACCTTTCCGTATGTGAGAGTAGTTGTTCTGAGAGTACCTTCGTCTACAGGTAATGTTCAGACATTCTCTTACCTTTCTTCACTAGGGTAGATTTCCCACAGACTACCGTCCCCCCTCTACGGTAGGAGTGATGTCACCATATAAGAAGTTACCCTAGTATGACTCAGGTCCCCCACTATC