paired-end mapping and SAM info.

[dkrtndhkd]

Hi, I have an fundamental question...

as you know, paired-end fastq files(ex. 'asdf.for.fastq' and 'asdf.rev.fastq') can be aligned to 'asdf.sam'

As I know, aligner program aligns each forward read and reverse read of paired-end read(which have same seq ID) seperately.

So, we can see that forward read can be aligned but reverse read cannot.

however, I think that forward and reverse read must be merged before aligned and the merged one read should be aligned to reference as a 1 set.

please give me any advice.

Sorry for NEWBIE question.

[swbarnes2]

"however, I think that forward and reverse read must be merged before aligned and the merged one read should be aligned to reference as a 1 set."

Two of the most popular aligners are bwa and bowtie, and for both of then, you must keep your fastqs separate, and not merge them, if you want the software to understand that you reads are paired.

I recommend starting with bwa, because the command line options are a lot less daunting than bowtie.

[dkrtndhkd]

Yes, I use bwa aligner and how to use it.

this post is about the 'concept' of paired-end read process.

I don't understand why they don't merge for/rev fastq and align them seperately.

[westerman]

If I am understanding your 'concept' question correctly, then my answer is that you can not merge reads together unless they overlap. For many (most?) sequencing projects there will be no overlap. Ergo the need to align separately.

I suppose you could put together your reads with, say, 20 Ns separating them and then letting BWA/Bowtie do alignment on that merged read but that seems prone to error.

Additionally, by not having a merged read then it is possible to detect transversions and other arrangements where the reads do not lie close to each other.

[westerman]

Another way to read your question would be "why do they not have a single merged R1/R2 (forward/reverse) file to be read in instead of forcing us to give the program two input files? The program could then separate the single file into two parts before alignment."

If this is your question then, not being an author of either, my answer would be that having the end-user specify which reads are R1 and which are R2 is less error prone than having all reads in one file. FastQ and FastA have no fixed way to specify R1/R2 reads.

BTW, I find Bowtie2 to be less daunting than BWA simply because of the 'preset options' (e.g., --very-fast or --sensitive-local, etc.) Bowtie2's command line is

bowtie --very_fast -x my_index -1 R1_file -2 R2_file -S Output_Bam

Whereas with BWA I have to do two 'bwa aln' and an 'bwa sampe' to obtain similar output.

That said, both are very good programs and a person should be familiar with both.

[dkrtndhkd]

Thank you westerman!!!

Your second reply was what i wanted to ask.

and, further question!

I understand that for reason of less error prone, illumina makes two(paired-end) fastq files.

but the two aired-reads actually come from 1 sequence -

for example, for.fastq and rev.fastq has information about ID, seq, quality with 101bp,

the original read that illumina sequencer machine read has 202bp sequence.

am i understanding it correctly?

then, we put two input files-for/rev fastq file-to bwa and bwa align each paired-read seperately so paired-reads don't aligned to neighboring position.

but i think the paired-reads originally come from 1 sequence with 202bp - so i don't know why bwa doesn't merge them first and then align to reference, rather than align each paired-reads seperately.

[swbarnes2]

"but i think the paired-reads originally come from 1 sequence with 202bp "

No. You have a whole pool of DNA fragments of differing sizes, and you read 101 bases from one end inwards, and then 101 bases from the other end inwards. The people prepping the library will have an idea of the average fragment size, but that's just an average.

[westerman]

To emphasize swbarnes's comment.

For example one of the DNA fragments could be physically 500 bases long thus giving you a read from base 1 to base 101 and another read from base 399 to base 500. A different fragment in the sequencing run might be physically 150 bases long thus giving you a read from base 1 to base 101 and another read from base 49 to base 150.

[dkrtndhkd]

Oh, thank you. I had an wrong understanding about paired-end sequencing.

then, each fragment does not have uniform length, why paired-end sequencing was developed?

the length that sequencing machine reads is 101bp(=same) for both single end and paired end, so the error rate of single/pair end sequencing is same.

the speed of sequencing may be doubled for paired-end sequencing. -> is this only strong point of paired-end sequencing?

[dkrtndhkd]

and, if the paired-end read sequencing result anyway comes from 1 fragment with various length(for example, 150~500bp),

the aligned position of two read(1 forward read, 1 reverse read and they have same ID in fastq file) must be within ~300bp in theoretically. am i right?

[swbarnes2]

Oh, thank you. I had an wrong understanding about paired-end sequencing.

then, each fragment does not have uniform length, why paired-end sequencing was developed?

the length that sequencing machine reads is 101bp(=same) for both single end and paired end, so the error rate of single/pair end sequencing is same.

the speed of sequencing may be doubled for paired-end sequencing. -> is this only strong point of paired-end sequencing?

For the same amount of work done at the lab bench, you get twice as much data. It does take twice as long on the instrument, and requires twice as many instrument reagents, but almost all of that time is unattended.

Having paried end data can help you a lot with de novo assembly.