BFAST + GATK -> strand bias?

[Boel]

Hi All,

I have HiSeq exome data, 75 b paired end. I've used bfast to align, which, if I am not mistaking, converts one end to its complement so that both members of a pair are attributed to the same strand, the pos one, in the resulting bam file.

If this is true it leads to a problem in GATK (when filtering calls), simply that one can not use strand bias tests (they are all highly sign, all reds are on the same strand). Also, this would also create problem in the read position rank tests, as the 'best' end of every other read is annotated as its 'good' end.

So the question is: Am I missing something, or are the above conclusions correct?
Also, is there a way to circumvent this?

Thanks a bunch,
Boel

[nilshomer]

With the newest version of BFAST, you can have the input reads on be the opposite strand to properly represent paired end reads. BFAST will not reverse compliment one end, but the conversion to FASTQ may do so (a new "-k" option avoids this).

What is your input data, FASTQ files?

You may get more traction at bfast-help@lists.sourceforge.net.

[Boel]

Originally Posted by nilshomer

With the newest version of BFAST, you can have the input reads on be the opposite strand to properly represent paired end reads. BFAST will not reverse compliment one end, but the conversion to FASTQ may do so (a new "-k" option avoids this).

What is your input data, FASTQ files?

You may get more traction at bfast-help@lists.sourceforge.net.

Thanks.

I started with qseq files, converted them with the ill2fastq.pl and then aligned with bfast (bfast+bwa-0.6.5). Did not use the -k option.

Not sure that this does create a bias, thats what I am trying to figure out. Do you know?
According to sam format all reads are on the same strand as the reference, which might make this a non-issue. But I must say that I am confused right now.

[nilshomer]

The ill2fastq.pl script will reverse compliment one of the ends, so they are mapped onto the same strand. You can try with the newest release and the "-k" option, as well as supplying the proper pairing information (there is a new "postprocess" pairing option).

[Boel]

Originally Posted by nilshomer

The ill2fastq.pl script will reverse compliment one of the ends, so they are mapped onto the same strand. You can try with the newest release and the "-k" option, as well as supplying the proper pairing information (there is a new "postprocess" pairing option).

I am correct in assuming that using bfast in the way I have does create a bias?

Further, when looking at my reads in IGV most (70%) have a insert size that is positive, while my correct mean insert size should be around -12 (overlapping). Does this suggest that something has gone wrong in the mapping?

[nilshomer]

Originally Posted by Boel

I am correct in assuming that using bfast in the way I have does create a bias?

Further, when looking at my reads in IGV most (70%) have a insert size that is positive, while my correct mean insert size should be around -12 (overlapping). Does this suggest that something has gone wrong in the mapping?

Not sure as I don't have enough information. I have tried mapping with pairs that should have a mean insert of zero without problems. Please try the newest version of BFAST and post your results as well as enough information for us to debug.