[chenyao]

Possibly not. Standard protocol for the PE read is that F5 is done first, then F3. So, if that is the information stored in the bam file, that would explain your results.

Are you doing the mapping yourself? Or did your provider do the mapping?
I have never used Top hat. I am not sure how it assigns the read designations. Can you look at your bam file in a viewer like IGV? Might be possible to see some of the mapped reads and determine whether the long (F3) reads are called "read1" or "read2".

If you are getting high mapping rates from your F5 reads, then that is great news, in a way. It would indicate that ABI has fixed their issues with the F5 chemistry. The failure to map F3 reads might be the result of short inserts in your amplicons then. That is reads continuing into the adapter on the other side of the insert. Depending on the methodology that Top hat uses for mapping, this might prevent the read from being mapped.
--
Phillip

I mapped the reads by myself. The provider also give the basic statistic results which shows F3 has higher mapping rates. I paste their reply in the previous post (average F3 mapped 35M, F5 mapped 8M). So I think the first explanation is reasonable."Standard protocol for the PE read is that F5 is done first, then F3"

[chenyao]

Dear all ,

Unfortunately, The read 1 is F3 . I mapped F3 reads by Tophat separately and found the mapped number is similar with read 1. Also, I run the accepted_hits.bam with cufflinks and it reported the read-type is "53bp x 50bp", but the pair reads is 50*25 bp.

Below is my tophat command, anything wrong:

tophat --color --qual -r 200 -p 8 --library-type fr-secondstrand -o /tmpData /data1/mm9_color /data1/F3.csfasta /data1/F5.csfasta /data1/F3.qual /data1/F5.qual

I found the reads in original data were named by "123_F3" and "123_F5BC", should I convert it to "123_F3/1" and "123_F5/2" for tophat to read?

[marcowanger]

In your F3 read sets, is there any dot in the BEGINNING part of the read?

I mean .ATGGGATT

I have tried SOLiD v3, the read set seems to have a large number of un-usable reads like this, not sure if it causes your problem Che Yao, may you check your dataset?

[chenyao]

In your F3 read sets, is there any dot in the BEGINNING part of the read?

I mean .ATGGGATT

I have tried SOLiD v3, the read set seems to have a large number of un-usable reads like this, not sure if it causes your problem Che Yao, may you check your dataset?

I don't know. It's a color-space data. I tried to transfer it to fastq by "solid2fa", but it seems failed, the data become to:

@1_15_97
T12310123033313323122113012323023202122223322003122
+
65&%1,+).+*%%.'*&'&&1)&%:1(,%&'*&/)=+.(2*+(.&*%*-*

not the "ATCG" form.

[pmiguel]

Looks like it worked to me. Your sequence is the "T" prefixed line. Each number following is a "color". SOLiD normally produces "color space" data. If at all possible, you want to leave the raw data in that format because it allows error checking to be done during mapping.

What marcowanger wanted you to check for were missing bases in the sequence fields encoded as ".", instead of the normal 0,1,2,3. Those missing bases choke some aligners, evidently.

--
Phillip

[chenyao]

Looks like it worked to me. Your sequence is the "T" prefixed line. Each number following is a "color". SOLiD normally produces "color space" data. If at all possible, you want to leave the raw data in that format because it allows error checking to be done during mapping.

What marcowanger wanted you to check for were missing bases in the sequence fields encoded as ".", instead of the normal 0,1,2,3. Those missing bases choke some aligners, evidently.

--
Phillip

Thank you. So as marcowanger said, the missing base "." should be after the "T". I will check it.