Closed ZuyaoLiu closed 2 years ago
I just found out the error disappears if I just process one chromosome. But that would lead to no SV detected with LEVIATHAN. And if I process all chromosomes together, the error shows up again.
Hi,
I guess the problem comes from the BX tag in your bam. LRez may not recognize that it is the Haplotagging technology since the BX tag ends with "-1", instead it assumes it is 10X genomics technology and expects the barcode to be a ACGT word. We assumed the "-1" pattern at the end of the barcode was specific to 10Xgenomics data. It seems not to be the case. Is the "-1" pattern present also in your Fastq files ? Or is it the mapper which added the "-1" ? By the way, which mapper did you use to get your bam file ?
Claire
Hi clemaitre,
I aligned the reads to ref using EMA. To do this, I manually convert haplotagging barcods to 16 bp sequences and did mapping. After that, I reverted the BX tag in bam files back to haplotagging barcodes. So the "-1" comes from the EMA mapper. I just tried to remove "-1" by "samtools view -h ../1_map/MA_fem_13.BXnum.bam |perl -pe "s/-1\t/\t/" |samtools view -bS - -o MA_fem_13.new.bam", but the error was still there.
Thank you .
Thank you @ZuyaoLiu for these helpful details. This seems thus that the error is not related to the barcode format (even if it is problematic for the moment in LRez that haplotagging tags may end by "-1")...
Could you give us access to your problematic bam file to help us debugging ? (you can send a download link for instance at claire[dot]lemaitre[at]inria[dot]fr)
Claire
Hi @ZuyaoLiu,
the stoi error you got with LRez was fixed, you should now be able to index your bam files using the latest commits (and the "-1" at the end of the barcodes should no longer be a problem neither). The stoi error was due to some contigs whose size is smaller than the windowSize (windowing is used in LRez to multi-thread the indexation).
A similar piece of code was also present in LEVIATHAN (which also uses windowing but for SV discovery, thus with a potential similar bug if contigSize<windowSize). This has also been fixed in the latest commit of Leviathan. Could you please test on your data and tell us if it runs without error ?
Best, Claire
Hi Claire,
I just tested with the bam files, and it worked. Thanks for your help!
Best,
Zuyao
Claire Lemaitre @.***> 于2022年3月28日周一 18:03写道:
Hi @ZuyaoLiu https://github.com/ZuyaoLiu,
the stoi error you got with LRez was fixed, you should now be able to index your bam files using the latest commits (and the "-1" at the end of the barcodes should no longer be a problem neither). The stoi error was due to some contigs whose size is smaller than the windowSize (windowing is used in LRez to multi-thread the indexation).
A similar piece of code was also present in LEVIATHAN (which also uses windowing but for SV discovery, thus with a potential similar bug if contigSize<windowSize). This has also been fixed in the latest commit of Leviathan. Could you please test on your data and tell us if it runs without error ?
Best, Claire
— Reply to this email directly, view it on GitHub https://github.com/morispi/LEVIATHAN/issues/5#issuecomment-1080834726, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALYRQ4HKI4WI4XYT6Y7PUQLVCHJ6XANCNFSM5Q7MKUGQ . You are receiving this because you were mentioned.Message ID: @.***>
Hi Pierre,
I'm using haplotagging data with LRez and LEVIATHAN. However, I always got this error when trying to index bam files. The bam file looks like this:
Any idea about it?
Thank you !!