Thank you both for your thoughts and questions.
Jon Keats, tophat version was indeed 1.4.1. I have not used the GTF option in tophats. Would that be a good idea? Do you recommend it?

I got an email from the lab also. It seems like I was correct and they had forgot about the length of the adaptors.. Even more incentive to anyone else that reads this to calculate your paired read inner distance based on your reads, and don't trust the lab's information.

Here's a more detailed summary of one of my samples when mapping with different --mate-inner-dist and --mate-std-dev parameters (all other parameters are the same).

As you can see, very little change in number of mapped reads but drastic decrease in properly paired reads.

This below is from the Picard tools MarkDuplicates. These numbers are only from the mapping with Mean=150 because the 125 and -50 gives very very similar numbers (almost identical percent_duplication numbers).

Am I right in interpreting the field PERCENT_DUPLICATION meaning that 0.25% of the reads are duplicates? Since all three mappings gave similar numbers of duplicates I don't think this is the reason why the number of properly paired reads decreases. What I'm now trying to figure out is how tophat determines when a read is properly paired or not, but it's not very easy to find this information.

Another question I have that you might be able to answer so I can start mapping with the correct inner distance. I subtracted the read lengths and the adaptors from the size selected fragments and got closer to the number -50 but not quite. Is there anything more that you should subtract besides both adaptor lengths? barcodes?

If you have any more ideas or suggestions, please let me know. I will keep you updated if I find out more.

In my experiment, the fragment size is around 260bp, and the read length is 90PE.

At first my calculation was wrong. I thought the inner distance should be around 100. After that I realized the correct mean inner distance should be 260 - 121 - 90*2 ~= -40, so I run tophat again.

When I compared the results by "samtools flagstat", the proper aligned paired-ends was about 97% for inner distance 100, and about 50% for inner distance -40.

Then I compared the sam files generated by tophat (converted from bam file), I found that for most of the reads, the alignment were the same, only the flags were different. If I remember correctly, the flags generated with -r 100 were 2 more than the flags generated with -r -40, for example, for the same read, the flag is 83 for -r 100, and 81 for -r -40. According to samtools definition, a flag of 0x2 means "each segment properly aligned according to the aligner".

I'm still trying to figure our how tophat works with negative inner distance.

Quote:

Originally Posted by glados

Thank you both for your thoughts and questions.
Jon Keats, tophat version was indeed 1.4.1. I have not used the GTF option in tophats. Would that be a good idea? Do you recommend it?

I got an email from the lab also. It seems like I was correct and they had forgot about the length of the adaptors.. Even more incentive to anyone else that reads this to calculate your paired read inner distance based on your reads, and don't trust the lab's information.

Here's a more detailed summary of one of my samples when mapping with different --mate-inner-dist and --mate-std-dev parameters (all other parameters are the same).

As you can see, very little change in number of mapped reads but drastic decrease in properly paired reads.

This below is from the Picard tools MarkDuplicates. These numbers are only from the mapping with Mean=150 because the 125 and -50 gives very very similar numbers (almost identical percent_duplication numbers).

Am I right in interpreting the field PERCENT_DUPLICATION meaning that 0.25% of the reads are duplicates? Since all three mappings gave similar numbers of duplicates I don't think this is the reason why the number of properly paired reads decreases. What I'm now trying to figure out is how tophat determines when a read is properly paired or not, but it's not very easy to find this information.

Another question I have that you might be able to answer so I can start mapping with the correct inner distance. I subtracted the read lengths and the adaptors from the size selected fragments and got closer to the number -50 but not quite. Is there anything more that you should subtract besides both adaptor lengths? barcodes?

If you have any more ideas or suggestions, please let me know. I will keep you updated if I find out more.

If you are using human data I'd recommend using the GTF option in general.

From your mark duplicates table you have 24,902,406 unique alignment events [(READ_PAIRS_EXAMINED x 2) + UNPAIRED_READS_EXAMINED] in the -r 150 test. Look to see if that number is also changing as you modify -r

The percent duplicates you are seeing is fairly good or typical of illumina mRNAseq libraries with > 20 million fragments.

Indeed icebsd, it seems like that.
I got a response from Cole Trapnell earlier where he said that I shouldn't worry too much about the negative inner distance since both tophat and cufflinks are able to handle that well. I asked about the properly pairing rules as discussed in this thread, and he said he would forward this question to Daehwan as he has been working on that tophat code recently. I have not gotten a response from Daehwan, if I do I will update in this thread. Perhaps he is willing to comment himself in this thread.

edit: Jon Keats: The [(READ_PAIRS_EXAMINED x 2) + UNPAIRED_READS_EXAMINED] are almost identical for the three different mappings. It is less than 20 reads difference.

Okay so this is an important point. You need to watch the number of uniquely mapped reads NOT the total number of reads mapped, at least in my opinion (To do so use Picard CollectAlignmentMetrics over Samtools Flagstat). Second watch the percentage of aligned reads which are unique events. What I think you are seeing is that as you alter the -r value you are increasing the number of non-unique mappings (ie. reads that map to multiple locations, tophat will print the same read multiple times in the bam file) while not altering the number of uniquely mapped reads. At the end of the day you want to limit the number of multiple mapped reads as these reads will contaminate your gene expression estimates.

Jon Keats, as I mention earlier the number of duplicates is approximately the same in the three different mappings. I have used Picards CollectAlignmentSummaryMetrics in addition to the MarkDuplicates and it does not give much information, mostly zeros in every column (which I have noticed to be the case for other users as well, so it seems to be in order). I can extract one column for you to see:

I still think that TopHat flags more reads as properly paired when given a higher mean inner distance, though I'm unsure of why that is. It would be best if someone from the TopHat team could give us clarity as to why, and in the meantime I think it's a good idea not to trust the reads flagged as properly paired too much.

What people typically do is to map the library (or a subset) to the genome (with Bowtie / BWA), compute an estimate of the fragment size (both mean and Standard Deviation, option --mate-std-dev).
Don't forget to substract the size of the reads to the mean fragment size and use this as your "mate-inner-dist".
A possible command-line to calculate this is: (this assume that the read length is constant)

Alternatively, if you can estimate the fragment size during the library preparation, that should also work.

I have no idea how sensitive this parameter is and its effect on the resulting mapping. Anybody has comments on that?

Hope that helps,

Nicolas

Hi Nicolas, I need to do this step, but I was wondering what the command for using 2 paired end read files (sample_R1.fastq and sample_R2.fastq) to map to a reference transcriptome would be?
How would we go about mapping a few (as you said a million or so) reads to a ref transcriptome?

Hi,
It would work the same if your File.mapped.bam has been aligned to a transcriptome index.

By the way, I have a general question related to this -r parameter:
Did you guys tried to omit this parameter (or as I did, accidentally forgot to put it)? I know the manual says "There is no default, and this parameter is required for paired end runs.", but it does work quite well if you forget it!
I tested with and without the option, on a same dataset and the difference was very marginal: 1 junction was not found without the parameter (out of >100,000) and 2000 alignments were missing (out of >700,000).
I have no idea what the default value is. The accepted_hits.bam file is well formatted and the reads are properly paired.
Similarly, I always wanted to test a bunch of values and see how sensible this parameter is. My assumption is "not very much", but I may be wrong. Did anybody tried?

Please let me know if I am the only one to get to work without the -r parameter.

TopHat doesn't have much need for the mean inner distance nowadays, and will even less in the future, according to Cole Trapnell. If you don't specify -r with a value it will default to 50 as it says in the release notes from an earlier version, they just haven't updated the manual yet.

I looked again at the Picard MarkDuplicates output and I think I may have interpreted the percent_duplication=0.250123 wrong. Perhaps they mean it is as high as 25%, not 0.25% as I initially thought. But when reading about what both samtools rmdup and Picardtools MarkDuplicates actually does: Marking reads as duplicates if they have the same 5' coordinates, then it doesn't seem strange that so many reads were marked as duplicates, considering that my inner distance is -50 and my reads are very overlapping so sometimes the reads will start on the same coordinate.

I did some experiments for the same sample using Tophat 1.3.3. It seems the -r parameter of Tophat will have influence on cufflinks analysis. When I use a wrong -r parameter, the Tophat output.bam file change not much( you can see from IGV). But when it comes to cufflinks, some genes that have a FPKM value(read coverage in IGV) now have a zero FPKM. So I guess that, cufflinks will need the proper paired information to estimate gene's FPKM.
I am wondering if anyone observe that.

TopHat doesn't have much need for the mean inner distance nowadays, and will even less in the future, according to Cole Trapnell. If you don't specify -r with a value it will default to 50 as it says in the release notes from an earlier version, they just haven't updated the manual yet.

Hi Glados

Reading the thread and your comments. I have a query about setting up the parameter in -r. I also tried to get the information of insert size from the sequencing lab and they said me it to be 180 bp for 96 bp illumina paired end reads. So what can be the ideal set up for -r for me will it be (180- (2x94))=-8. Do I need to have the -8 (aaprox -10) as - r or Another way could be like i keep it default.

Make sure the lab meant 180 as insert size and not inner distance. If I were you, I would try with both the default and -8 as inner distance. See if you get any differences in tophat output. You can view the assembly in a genome browser, like IGV, and see if the reads on average overlap approximately 8 bp. If you are certain it is -8, I would use it in tophat.