FastQC still showed "GGGGGGG" as over-represented sequence with "No Hit" Source even after --trim_poly_g in fastp.

[denvercal1234GitHub]

Hi there,

Thanks for the tool.

I have some paired-end bulkRNAseq. I ran fastp as below with --trim_poly_g but in the FASTQC report for a sample, there was still shown issue with over-represented sequence of GGGGGGGG... in the R2 read. with "No Hits" in the Source.

Would you mind giving me some pointers to address this issue?

Thank you for your help.

fastp \
    --adapter_fasta /ceph/project/borrowlab/qnguyen/RAW_bulkRNASeq_TMNCTFHTREGCD8_QNN2024Aug19/X204SC24072759-Z01-F001_02/01.RawData/for_Trimming.fasta \
    --adapter_sequence AGATCGGAAGAGCACACGTCTGAACTCCAGTCA \
    --adapter_sequence_r2 AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT \
    --qualified_quality_phred 5 \
    --unqualified_percent_limit 50 \
    --n_base_limit 15 \
    --overlap_len_require 30 \
    --overlap_diff_limit 1 \
    --overlap_diff_percent_limit 10 \
    --length_required 150 \
    --length_limit 150 \
    --trim_poly_g \
    -i "$file" \
    -I "$r2_file" \
    -o "$output_r1" \
    -O "$output_r2"

Referenced at OpenGene/fastp#589

[s-andrews]

The overrepresented sequences in FastQC just search (by default) the first 50bp of each sequence. You have 150bp sequences.

When you trim polyG it will trim from the 3' end back.

The most likely explanation, assuming you've run fastp correctly, is that you have sequences which start with polyG but move into something else before the end of their 150bp length. If that's the case then neither program is doing anything wrong here.