Open pdimens opened 1 year ago
@clemaitre is it because of this line? https://github.com/morispi/LRez/blob/c9b378c53d81cf7cc28516eeefe2045b02583ecc/src/utils.cpp#L10 That it expects the BX:Z:AXXCXXBXXDXX to be the end of the line with nothing following it?
Hi @pdimens,
sorry for the delay of my answer.
The issue does not come from the line of code you are pointing at because the regular expression is applied only on the value of the SAM TAG. This string value is obtained with the function getTag()
from the htslib library that handles the parsing of SAM/BAM files. In the example below :
... BX:Z:A95C26B84D96 1:N:0:TATCAGTA+TTACTACT
getTag("BX:Z", value)
should return the string "A95C26B84D96".
However, the Tag/field that follows the BX tag in your example (eg : 1:N:0:TATCAGTA+TTACTACT
) seems not to have the correct format : "TAG:TYPE:VALUE
, whereby TAG
is a two-character string that matches /[A-Za-z][A-Za-z0-9]/
(cf. https://bioinformatics.stackexchange.com/questions/3979/how-does-htslib-samtools-access-optional-bam-fields). Therefore htslib may probably not recognize it as a proper TAG field and instead may concatenate it to the barcode value.
Have you an idea at which step of your pipeline such fields were introduced ?
Best, Claire
Thank you for your reply. This additional tag was produced by UMItools and added to the FASTQ sequence headers. In the FASTQ spec, the comment line is valid, but it gets invalidated in the SAM spec when that information is carried over in alignment. These are things I've discerned since posting the original issue. I have since created a python script to clean the SAM file, and I agree that one should be more diligent about adding fastq headers with SAM-spec TAG:TYPE:VALUE
. However, the inclusion of un-tagged comments in FASTQ files is fairly commonplace, so I wonder if it would be worth adjusting the regular expression to recognize the AxxCxxBxxDxx tag up until a whitespace delimiter to cushion against these FASTQ comments carrying over into sam files?
Thank you for this insightful suggestion, we will keep this in mind for future developments.
@clemaitre in addition to the previous suggestion, there are circumstances where the BX:Z:
tag is followed by more legal SAM spec tags but LRez does not distinguish it because there isn't a newline character immediately following the BX:Z:
tag. For example, the source FASTQ file can have read headers like this:
@A00814:267:HTMH3DRXX:2:1101:4580:1000 BX:Z:A02C01B11D46 RX:Z:GAAACGACCAACA+CGAACACGTTAGC QX:Z:F,FFFFFFFFFFF+FF,FFF:FFFFFF
The comments of which are legally added to the SAM/BAM file via (e.g.) bwa mem -C
, but are considered illegal due to the rigidity of the capturing regex in LRez.
Hello,
I'm trying to use LEVIATHAN and require the barcode indices from LRez. Introduced a step in my workflow that uses
samtools view
to filter reads on mapping quality, and it seems that doing so has created issues with LRez no longer recognizing the BX:Z: tags (where it did previously). These are haplotagging data, where the index is AXXCXXBXXDXX.Unless I'm mistaken, my bam files are formatted normally:
Do you have insights to provide on this that may reveal a mistake on my end or a bug in LRez? While the workflow is listed in the
@PG
tags, the steps are:bwa mem
samtools view
samtools sort
sambamba markdup