insert size pre and post trimming

Question

I have a problem here with my rna seq data:

Sequencing details:

rRNA was removed, followed by cDNA preparation and generation of stranded libraries using the TruSeq Stranded Total RNA Sample Prep Kit. Sequencing performed on the HiSeq2500 platform (Illumina) to generate 2 × 125 bp paired-end reads

Alignment and preprocessing

reads were aligned using tophat2(std aligner in pipeline at core (--library-type fr-firststrand), unfortunately the original unaligned files were purged and i only have access to this aligned file which i converted to fastq using following steps

1. samtools sort -n sample.bam -o sample_sorted.bam
2. bedtools bamtofastq -i sample_sorted.bam -fq sample_1.fq -fq2 sample_2.fq (get a lot of mate skipping errors here)
3. check for these reads for adapters and trim them and again use hisat2 (with --rna-strandness RF)

trimmed reads

Reads were trimmed by passing parameters --adapters adapters.file --adapter-trim-end RIGHT --length-dist --threads 12 --adapter-min-overlap 7 --max-uncalled 250 --min-read-length 25 -- to FLEXBAR version 2.4

adapters for all samples using multiqc

fastqc sequence length pre trimming

fastqc sequence length post trimming

rmats error

Incorrect readLength. sample.bam has a read length of 114, while readLength param is 125

picard error on aligned bam from hisat2)

ProcessExecutor 2 "Not creating insert size PDF as there are duplicated header names: All_Reads"

snapshot of picard insertsize metrics file

Questions

1. Is my approach flawed at some step?
2. why do i get different read lengths error for each sample when i process it through rmats when i specify len as 125?
3. why is no histogram being produced when using picard insertsize metrics?
4. is normal to see the graph shift to the right after trimming?

insertsize for all samples (data from picard collectinsertsize compiled using multiqc)

Answer 1

1. It's not an unreasonable approach. rMATs is rather picky about its input, but it seems you've noticed that.
2. rMATs can't handle trimmed reads. It also can't handle soft-clipped reads. You might as well not trim. You'll get a lower alignment rate, but your only other choice would be to either exclude the trimmed reads or trim everything down to the same length.
3. You have a mixture of RF and FR alignments and the plotting script can't handle that.
4. Assuming you mean the read length distribution, it's actually shifted to the left, not the right. You had a single length before and a long left tail after trimming.