damapper maps a sequencing run, but daligner reports no significant mappings

[leucinedreams]

I have a dataset that maps to a reference .dam nicely using damapper, but when I attempt to map with the same file using daligner, either to a reference genome .dam or to itself, it returns zero hits. I've tried to incrementally increase the permissiveness by increasing -w and decreasing -h, but still nothing. Mapping the reference .dam against itself also returns no mappings, though I don't know if that's a good way to test whether my install of daligner is broken.

[leucinedreams]

Running simply daligner ens38.dam mySample.db -v returns

Building index for ens38 ` Building index for mySample Kmer count = 13,665,341 Using 0.41Gb of space Segmentation fault (core dumped)`

[leucinedreams]

swapping the samples as

daligner mySample.db ens38.dam -v

results in it segfaulting before acknowledging the reference dam file:

Building index for mySample ` Kmer count = 13,665,341 Using 0.41Gb of space Segmentation fault (core dumped)`

[leucinedreams]

Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with

DBsplit -s100 -x1000 mySample.db

then running with a partition

daligner ens38.dam mySample.1

[thegenemyers]

Sorry I wasn't more help, but glad to hear you figured it out. I'll review the code and put in an overflow check so hopefully the next time it happens to someone they get a friendlier exit :-) My apologies, Gene

On 2/6/18, 5:49 PM, leucinedreams wrote:

Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with

|DBsplit -s100 -x1000 mySample.db|

then running with a partition

|daligner ens38.dam mySample.1|

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/thegenemyers/DALIGNER/issues/76#issuecomment-363487058, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkkNhESHRVmLtreRYtngszKBjHrNzd-ks5tSIKKgaJpZM4R5n3b.

[leucinedreams]

It's a pleasure to play the role of the cautionary tale to future daligner users! Cheers!

[thegenemyers]

I was expecting to find an unguarded request for memory in my code, which would have explained the crash you were getting, instead of an error message. But I checked all my code, and every time I allocate or realloc memory there is a check and an error message printed with an exit if the allocation did not work. So I'm wondering how the crash happened. Could you do me the favor of recompiling daligner with the -g option, running it in gdb (or lldb) and giving me a backtrace (bt command) from where the error occurs? -- Gene

On 2/6/18, 5:49 PM, leucinedreams wrote:

Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with

|DBsplit -s100 -x1000 mySample.db|

then running with a partition

|daligner ens38.dam mySample.1|

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/thegenemyers/DALIGNER/issues/76#issuecomment-363487058, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkkNhESHRVmLtreRYtngszKBjHrNzd-ks5tSIKKgaJpZM4R5n3b.