FastQC finds poly-A in second paired-end read for ChIP-seq sample

[mkareta]

I think polyA is the result of library prep method. Some methods add a strech of A to ssDNA which is used to prime second strand synthesis or ligating adapters. If they have used a kit for library prep the supplier should have some recommendation regarding best sequencing approach.

That's it nucacidhunter. After checking with the sequencing core I realized that they utilized a library prep kit which include poly-T end labeling. I'll trim that sequence and proceed as normal.

Thanks nucacidhunter and GenoMax!

[GenoMax]

If @nucaidhunter's explanation is applicable then it may be easy enough to get rid of the ~15 T's at the beginning. That stretch of low diversity may have affected the Q-scores for the rest of the read so you will have to live with that.

[nucacidhunter]

I think polyA is the result of library prep method. Some methods add a strech of A to ssDNA which is used to prime second strand synthesis or ligating adapters. If they have used a kit for library prep the supplier should have some recommendation regarding best sequencing approach.

[GenoMax]

Hi Geno,

Unfortunately this is common to all of the second reads (4 samples total).

That may indicate that something may have gone awry during this run. If there was no issue with the run then you may have to double check your own prep/strategy to see if something unforseen happened.

You may want to hold off on using the data until you find a satisfactory answer.

[mkareta]

That looks odd. Have you checked with your sequence provider to eliminate the possibility of some kind of hardware/reagent issue during this run? Is this the only sample that looks strange?

Hi Geno,

No I have not, I'm trying to get in touch with them now.

Unfortunately this is common to all of the second reads (4 samples total). I guess my concern is do I trim the first 15 nt and hope I can trust the remainder of the read? Would it be better to simply toss the second read in entirety and run my alignment and peak calling on the first read only?

I suppose I could trim, then align, and let the alignment stats inform me if the rest of the read is good or not.

[GenoMax]

That looks odd. Have you checked with your sequence provider to eliminate the possibility of some kind of hardware/reagent issue during this run? Is this the only sample that looks strange?

[mkareta]

Hi,

I apologize if this has been covered but I can't find an answer for the issue that I am seeing with some paired-end Chip-seq data.

In all of my samples the second read shows poor quality scores after ~15 nt, and it appears that those first 15 nt are a stretch of poly-a (as determined by FastQC). These were not trimmed, I just wanted to assess the quality of the reads up front. The first read of the pair looks good.

Any thoughts what could be causing this? Is this an issue with library prep?

Thanks