GemBS call - Multiple Errors & Error handlings about gembs

[heathsc]

I will work on making the error messages more informative to try and make it simpler to track down problems such as those you highlighted. Simon

…

On 27 Aug 2018, at 14:16, Ismail Moghul ***@***.***> wrote: I understand. As mentioned above, I managed to 'fix' the problems by simply rerunning the analysis repeatedly. If I do see something similar again, I will raise an issue here. Nonetheless, in the long run, it would be useful to implement a few of the points I mentioned in the first message above - particularly printing which sample an error originates from in STDOUT etc. before the error message.... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHPd0xNaaZUNCYu-ixpXdZQoXb6F01jks5uU-MogaJpZM4WIDS1>.

[IsmailM]

have updated above msg with other suggestions/issues wrt error reporting

[IsmailM]

Further to above, the gemBS call has finished and I have the following errors, Any idea what is causing them?

I've rerun the samples (i.e. remove associated files and a db-sync), but I still see the following issues.

• In:
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr1.err - chr1:1672448
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr17.err - chr17:37

[E::bcf_write] Broken VCF record, the number of columns at * does not match the number of samples (0 vs 1)

• In bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_@pool_4.err - chr14_GL:1

[W::vcf_parse] Contig 'chr14_GL' is not defined in the header. (Quick workaround: index the file with tabix.) 
[E::bcf_write] Broken VCF record, the number of columns at * does not match the number of samples (0 vs 1)

---

• In:
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr4.err - chr4:49628383
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr10.err - chr10:41713562
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr16.err - chr16:34790245
  • bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr21.err - chr21:8049828
  • bs_call_EGAZ00001016575_90/bs_call_EGAZ00001016575_90_chr1.err - chr1:125184571
    • Note this is a diff sample

[E::vcf_parse_format] FORMAT column with no sample columns starting at *

---

• In bs_call_EGAZ00001016574_90/bs_call_EGAZ00001016574_90_chr20.err

BsCall Exit Code -9 (displayed in stdout/stderr) with no error code etc in err log

[IsmailM]

The above errors disappeared when repeatedly deleting the relevant files and rerunning.

Moreover, the two samples that failed were of a much higher coverage (i.e. greater than 90X) than the rest (EGAZ00001016574, EGAZ00001016575) - as such it's possible that GemBS doesn't expect that large of an input?

[heathsc]

Could there be a problem with disk space that’s leading to the failures?

…

On 27 Aug 2018, at 12:42, Ismail Moghul ***@***.***> wrote: The above errors disappeared when repeatedly deleting the relevant files and rerunning. Moreover, the two samples that fails whereof much higher coverage (i.e. greater than 90X) than the rest (EGAZ00001016574, EGAZ00001016575) - as such it's possible that GemBS doesn't expect that large of an input? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHPdx-pI2l7u95ZpaMzBmmLixiZbb-tks5uU80ogaJpZM4WIDS1>.

[IsmailM]

That was the first thing I checked - there was a few TB of free space.

[heathsc]

Does the contig ‘chr14-GL’ exist in the reference?

…

On 27 Aug 2018, at 12:47, Ismail Moghul ***@***.***> wrote: That was the first thing I checked - there was a few TB of free space. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHPd505gFiP1NctpF_bNiH-BHwfAtKeks5uU84-gaJpZM4WIDS1>.

[IsmailM]

No, but it doesn't exist in the query BAM file either:

$ samtools view -H EGAZ00001016574_90.bam | grep chr14_GL
@SQ	SN:chr14_GL000009v2_random	LN:201709
@SQ	SN:chr14_GL000225v1_random	LN:211173
@SQ	SN:chr14_GL000194v1_random	LN:191469

[heathsc]

And the chr14_GL0000*_random contigs do exist in the reference given to the caller?

…

On 27 Aug 2018, at 12:53, Ismail Moghul ***@***.***> wrote: No, but it doesn't exist in the query BAM file either: $ samtools view -H EGAZ00001016574_90.bam | grep chr14_GL @sq SN:chr14_GL000009v2_random LN:201709 @sq SN:chr14_GL000225v1_random LN:211173 @sq SN:chr14_GL000194v1_random LN:191469 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHPdyWWvvgaxD-rVO3xFAoba7Zr1QL4ks5uU8_GgaJpZM4WIDS1>.

[IsmailM]

Yes they do

$ zcat hg38.fa.gz| grep chr14_GL
>chr14_GL000009v2_random
>chr14_GL000225v1_random
>chr14_GL000194v1_random

[heathsc]

It’s difficult to see where to go from here. If you could create a example dataset that consistently failed (or at least failed with a reasonable frequency) that you could share then we could try and track down the problem. Simon

…

On 27 Aug 2018, at 13:00, Ismail Moghul ***@***.***> wrote: Yes they do $ zcat hg38.fa.gz| grep chr14_GL >chr14_GL000009v2_random >chr14_GL000225v1_random >chr14_GL000194v1_random — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHPd5cDBtvvHSPvZQoMj6-IpM3maigeks5uU9FJgaJpZM4WIDS1>.

[IsmailM]

I understand.

As mentioned above, I managed to 'fix' the problems by simply rerunning the analysis repeatedly. If I do see something similar again, I will raise an issue here.

Nonetheless, in the long run, it would be useful to implement a few of the points I mentioned in the first message above - particularly printing which sample an error originates from in STDOUT etc. before the error message....