Open szpiech opened 8 years ago
Hello Dr. Szpiech,
I am currently using selscan v1.1.0b with the --ehh flag and noticed that my output includes multiple entries for a given core SNP (i.e. multiple rows with the same relative physical position). This seems to be inconsistent with the example output where it appears there is only one row for each core SNP. Is it possible that this is related to this error? I am currently trying with v1.1.0 to see if I get different output.
Thank you for any insight on this,
Rachel
Hi Rachel,
Would you please copy/paste the output you receive? This is probably related, although I haven't figured out what the problem is yet (and this seems to be a relatively infrequently used option). Also, do let me know if v1.1.0 works for you.
-Zachary
Hi Zachary,
Here is the first few rows of the .out file from the EHH command using v1.1.0b:
3585 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -1413101832 0.000000 0.000000 0.000003 0.000000 -1413101881 0.000000 0.000000 0.000003 0.000000 -520406471 0.000000 0.000000 0.000003 0.000000
I did rerun using v1.1.0 with the same input files and get very different results - no duplicate entries for physical position and a much smaller output file:
-99970 0.000000 0.007026 0.000941 0.000901 -99771 0.000000 0.007028 0.000966 0.000917 -99748 0.000000 0.007028 0.000966 0.000917 -99730 0.000000 0.007028 0.000966 0.000917 -99704 0.000000 0.007028 0.000966 0.000917 -99662 0.000000 0.007028 0.000966 0.000917 -99656 0.000000 0.007028 0.000966 0.000917 -99652 0.000000 0.007028 0.000966 0.000917 -99644 0.000000 0.007028 0.000966 0.000917 -99599 0.000000 0.007028 0.000966 0.000917
The output from v1.1.0 appears to be giving me more consistent results.
Rachel
On Jun 19, 2017, at 11:10 AM, Zachary A Szpiech notifications@github.com wrote:
Hi Rachel,
Would you please copy/paste the output you receive? This is probably related, although I haven't figured out what the problem is yet (and this seems to be a relatively infrequently used option). Also, do let me know if v1.1.0 works for you.
-Zachary
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/szpiech/selscan/issues/22#issuecomment-309505295, or mute the thread https://github.com/notifications/unsubscribe-auth/AIdate-VAlRzgHfbD__DntifrnBwsVFCks5sFquAgaJpZM4IjRJi.
Please use v1.1.0 for this computation, my apologies for the strange bug. I'll have to look carefully at the code again.
-Zachary
Great, I will use v1.1.0. Thank you for your help!
Rachel
On Jun 19, 2017, at 11:20 AM, Zachary A Szpiech notifications@github.com wrote:
Please use v1.1.0 for this computation, my apologies for the strange bug. I'll have to look carefully at the code again.
-Zachary
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/szpiech/selscan/issues/22#issuecomment-309507861, or mute the thread https://github.com/notifications/unsubscribe-auth/AIdatTLxb8-qeY7AFxdF01sMOS1dMjGzks5sFq3sgaJpZM4IjRJi.
Hi Dr. Szpiech, Is the segmentation fault error still occurring? I've been getting "segmentation fault 11" using both v1.1.0b (via the CMS package) and v1.2.0a (using selscan directly). I'm using gzipped tped files as input, which run fine for iHS and nSL (XPEHH is still running). Is this likely related to the above issue, or is this something on my end? Thanks, Erin
Hi Erin,
Is the segfault happening when you use --ehh? If so, it's probably the above bug, which I'm sorry to say I completely forgot about until you sent this message. A less than ideal work around would be to use v1.1.0 in the mean time.
-Zachary
Under some (currently unclear) circumstances, use of the --ehh flag can cause segmentation faults, bus errors, or output inconsistent with what is expected. v1.1.0 does not appear to be affected.