ChIP-seq: When trimming Input samples should we also trim ChIP samples?
1
0
Entering edit mode
6.2 years ago
salamandra ▴ 550

When we trim 3' ends of reads of a Input sample to improve their 'sequence quality', should we also trim by the same number of bases in 3' ends in corresponding ChIP samples even if sequence quality in ChIP samples is good? I mean, do ChIP and Input reads always have to be the same size?

ChIP-Seq QC • 1.6k views
ADD COMMENT
0
Entering edit mode

Thank you for your help.

In my case, some conditions were sequenced in a different company so the read length is different for distinct TFs. In that case I could trim for example the conditions with longer reads and lower sequence quality without facing criticism right?

ADD REPLY
2
Entering edit mode
6.2 years ago

My own quick perspective: all samples should be pre-processed in the exact same way. It may not change the overall 'feel' of the results, but you will face more criticism if you pre-process them differently without any major justification. If one sample was horrendously poor quality, then you could justify special treatment, but otherwise no.

Kevin

ADD COMMENT
0
Entering edit mode

Thank you.

When you say all samples are you referring to all samples of the same condition or all samples of all conditions? For e.g. We trim the ChIP and Input samples of one transcription factor (TF) and then want to compare the targets of this TF with the ones of other TF. Should we also apply trimming to ChIp/Input samples of the second TF?

ADD REPLY
1
Entering edit mode

Yes, the trimming step, performed prior to alignment, is one of those general steps that should be applied equally to all samples being studied. By not applying the same procedure to them, you are introducing bias for which you would have to correct later down the line, and opening the door to potential criticism should you aim to publish the work.

If it was shown that one particular sample was extremely poor quality, then you could justify special treatment for it, but you would have to monitor it's progress as you perform all downstream analyses. You could also justify different trimming and QC if your samples were fundamentally different, like, different wet-lab protocols, different sequencers, paired versus single-end reads, very different pull-down methods, etc., but you have not indicated that your two TFs of interest are different. Therefore, I would apply an equal type of trimming to all input controls and TF samples.

Hope that this helps.

ADD REPLY
0
Entering edit mode

Thank you for your help.

In my case, some conditions were sequenced in a different company so the read length is different for distinct TFs. In that case I could trim for example the conditions with longer reads and lower sequence quality without facing criticism right?

ADD REPLY
0
Entering edit mode

Well, these days, people will criticise you for absolutely everything and anything - lol

May I ask how different are the read lengths? - Are we talking about one platform being the Roche and the other standard Illumina 2x150bp?

ADD REPLY
0
Entering edit mode

I don't know the platforms, cause this data comes from previous student in the lab, but one condition has reads with 75bp and the other around 100bp

ADD REPLY
1
Entering edit mode

That's a frequent occurrence in labs - one guy/gal leaves and then there's data left lying around.

As it's not such a great difference, I would just trim these both in the same way. If you are mirroring a previous ChIP study, then they may have mentioned their exact methods and minimum permitted read length. If you're not sure, I would just trim to something like 50bp and then use Bowtie to align.

There are many posts on Biostars about best read length to use, and it's a matter of debate in fact. If you use >70bp reads, then you could use either Bowtie or BWA mem

ADD REPLY

Login before adding your answer.

Traffic: 2094 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6