-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@PG ID:bwa line containing @RG ID:... causes SAMFormatException #677
Comments
|
Field values cannot have tabs, yes. I agree is a bwa bug. But is an htslib/jtsjdk issue nontheless -- feel free to mark 'wontfix,' but I thought it was important to document in case someone else runs across this, as there are I think zero google hits for this. |
Thanks for documenting it here for folks to find it, and feel free to link the issue you log with BWA, as it likely needs to sanitize its output in this case. Also, you can modify your script/code not to produce tabs. |
I've also run into this problem. Unfortunately the workaround used by @lucacozzuto doesn't work in picardtools as the |
I've come across this problem as well when using Picard. My workaround has been to include "VALIDATION_STRINGENCY=LENIENT" in the Picard commands that throw this error. |
Thank you for opening this issue! Indeed, I just faced this problem while using |
Fyi, you can just use two backslashes: posting so others who stumble here like me can quickly fix it, until its properly escaped |
_(Foreword) This may actually be an htslib issue rather than specifically htsjdk_
Verify
I searched the issue tracker for the text: "clash"
Subject of the issue
Briefly, when read groups are added at the alignment step with BWA (instead of adding them later), bwa inserts the @pg BAM header line that includes its complete command line after the CL: key. However, when the command line string includes
-R @RG<tab>ID:xyz...
, the read groupID
is parsed as a new key by htslib/htsjdk's header parsing code. This causes an exception.I must further note that this only occurs when the command line actually has the literal "tab" character, which is most likely to occur when bwa is called from a pipeline stage where the command line was build programmatically. When running bwa from the command line and typing the
\t
escape sequence as a string, bwa parses it correctly but includes the original\t
in the @pg line, thus avoiding htslib/htsjdk interpreting ID: as a distinct key.The behavior can be replicated by running bwa from command line and typing
-R $'@RG<control-v><tab>ID:whatever<control-v><tab>SM:whatever<control-v><tab>PU:whatever'
This has not bit me 'til now as I am formally automating everything that was previously done with a hodgepodge of shell scripts.
Your environment
htsjdk included with Picard 2.5.0 from GitHub
Picard version: 2.5.0(2c370988aefe41f579920c8a6a678a201c5261c1_1466708365)
Steps to reproduce
Tell us how to reproduce this issue. If possible, include a short code snippet to demonstrate the problem.
bwa -R 'ID:anything'
followed by picardtools
Expected behaviour
No exception (ignore previously seen keys, at least on @pg lines)
Actual behaviour
htsjdk.samtools.SAMFormatException
as aboveProposed solution
ID: keys seen after the initial ID: on a @pg line should be ignored
Other commentary
The inclusion of RG at the alignment step is convenient and a better use of resources than doing a separate run of AddRemoveReadGroups.
The SAM specifications indicate that a command line follows CL:. This is imperfect, but I propose that bwa -R is common enough that htslib/htsjdk should ignore previously seen tags.
Workaround in the meantime
Pipelines should include escape sequence
\t
rather than literal<tab>
control characters in bwa command linesThe text was updated successfully, but these errors were encountered: