[tonybolger]

Many Thanks! If I may ask one more noob question, what indicated to you that the miseq trimming was enabled? I have been handed this data with very little information and would like to know how to spot it.

It's pretty easy - the read lengths vary. Because of the way illumina sequencing works, all sequences (in the same direction at least) have the same 'raw' read length before trimming.

[Jane M]

Hello everybody,

I am trying Trimmomatic for the first time for a few days on my paired-ends 100pb reads data. I am facing a problem: the 4 output files created are empty.

I want to use Trimmomatic with these parameters:

java -jar /Trimmomatic-0.30/trimmomatic-0.30.jar PE GLE7.R1.fastq GLE7.R2.fastq GLE7_paired.R1.fastq GLE7_unpaired.R1.fastq GLE7_paired.R2.fastq GLE7_unpaired.R2.fastq SLIDINGWINDOW:6:20 LEADING:20 TRAILING:20 AVGQUAL:20 MINLEN:36

The "output log" says:

TrimmomaticPE: Started with arguments: GLE7.R1.fastq GLE7.R2.fastq GLE7_paired.R1.fastq GLE7_unpaired.R1.fastq GLE7_paired.R2.fastq GLE7_unpaired.R2.fastq SLIDINGWINDOW:6:20 LEADING:20 TRAILING:20 AVGQUAL:20 MINLEN:36
Input Read Pairs: 61314232 Both Surviving: 0 (0.00%) Forward Only Surviving: 0 (0.00%) Reverse Only Surviving: 0 (0.00%) Dropped: 61314232 (100.00%)
TrimmomaticPE: Completed successfully

I tried several combinations of the parameters. I only got the output files not empty when using the MINLEN option lonely.

I don't think that my thresholds are too drastic for my data. Attached is the FastQC output.
Do you have any idea of what is happening?

Thank you in advance,
Jane

[kmcarr]

Hello everybody,

I am trying Trimmomatic for the first time for a few days on my paired-ends 100pb reads data. I am facing a problem: the 4 output files created are empty.

I want to use Trimmomatic with these parameters:

Trimmomatic, by default, assumes that FASTQ reads still use the very old ASCII phred+64 encoding for their Q-scores. Here is the quote from the Trimmomatic manual:

If no quality score is specified, phred-64 is the default for historical reasons but is correct only for the older Illumina machines / pipeline versions.If you are using the Illumina HiSeq or MiSeq, you will need to add –phred33. This will be changed to an 'autodetected' quality score in a future version!

Using that default Trimmomatic believes all your base calls are crap (<Q20). You have to add '-phred33' to your command line to change this default behvior. E.g.

java -jar /Trimmomatic-0.30/trimmomatic-0.30.jar PE -phred33 GLE7.R1.fastq GLE7.R2.fastq GLE7_paired.R1.fastq GLE7_unpaired.R1.fastq GLE7_paired.R2.fastq GLE7_unpaired.R2.fastq SLIDINGWINDOW:6:20 LEADING:20 TRAILING:20 AVGQUAL:20 MINLEN:36

[Jane M]

Trimmomatic, by default, assumes that FASTQ reads still use the very old ASCII phred+64 encoding for their Q-scores. Here is the quote from the Trimmomatic manual:

Using that default Trimmomatic believes all your base calls are crap (<Q20). You have to add '-phred33' to your command line to change this default behvior. E.g.

Yes, that was the problem! Thank you, it's working fine now.

Now that the main problem is solved, there are 3 details I would like to discuss:

- I read in this thread that Trimmomatic should be multi-threated. I have not found an option to do that. Is it possible?

- I don't clearly understand what is the keepBothReads. Could you please explain me in other words?

keepBothReads: After read-though has been detected by palindrome mode, and the adapter sequence removed, the reverse read contains the same sequence information as the forward read, albeit in reverse complement. For this reason, the default behaviour is to entirely drop the reverse read.

- Last point: I intend to keep both paired and unpaired reads. I will use tophat2 for alignment, which seems to deal with unpaired reads.
For gene fusion detection, I will use tophat2 --fusion-search. Do you know if it's a good idea to use unpaired reads for fusion detection? Should I set keepBothReads=true?

Thank you,
Jane

[kmcarr]

- I read in this thread that Trimmomatic should be multi-threated. I have not found an option to do that. Is it possible?

Use the '-threads <int>' option described in the manual or in command line usage message shown when your run trimmomatic with just the '-h' (help) parameter

java -jar <path to trimmomatic.jar> PE [COLOR="Red"]-threads <int>[/COLOR] -phred33 <inputFiles> <outputFiles> <trimmerParameters>...

Replace <int> with number of threads you wish to use. In my experience trimmomatic does scale much beyond 3-4 threads.

- I don't clearly understand what is the keepBothReads. Could you please explain me in other words?

Look at the figure on the top of page 5 of the Trimmomatic Manual. In part D of the figure it shows the case where the insert (green) is shorter than the read length such that you get read through of the insert into Illumina adapter at the 3' end (red). In such a case, with PE reads, read #2 will completely overlap read #1, as its reverse complement. No additional sequence information is provided by read #2. Trimmomatic's default behavior is to keep read #1 (after trimming the adapter (red) portion) as a singleton and discard read #2 since it is simply redundant information. The '-keepBothReads' option changes the default, read 1 and read 2 will be kept as paired reads.

- Last point: I intend to keep both paired and unpaired reads. I will use tophat2 for alignment, which seems to deal with unpaired reads.
For gene fusion detection, I will use tophat2 --fusion-search. Do you know if it's a good idea to use unpaired reads for fusion detection? Should I set keepBothReads=true?

I'm not familiar with Tophat fusion or how it would deal with the case of completely overlapping reads so I can't comment.

[Jane M]

Use the '-threads <int>' option described in the manual or in command line usage message shown when your run trimmomatic with just the '-h' (help) parameter


Replace <int> with number of threads you wish to use. In my experience trimmomatic does scale much beyond 3-4 threads.

Thank you kmcarr!

Look at the figure on the top of page 5 of the Trimmomatic Manual. In part D of the figure it shows the case where the insert (green) is shorter than the read length such that you get read through of the insert into Illumina adapter at the 3' end (red). In such a case, with PE reads, read #2 will completely overlap read #1, as its reverse complement. No additional sequence information is provided by read #2. Trimmomatic's default behavior is to keep read #1 (after trimming the adapter (red) portion) as a singleton and discard read #2 since it is simply redundant information. The '-keepBothReads' option changes the default, read 1 and read 2 will be kept as paired reads.

It's clearer now, thank you.

I'm not familiar with Tophat fusion or how it would deal with the case of completely overlapping reads so I can't comment.

If someone has experience with detection of gene fusion and unpaired data, I would be interested in hearing it.

[luiscunhamx]

Hi kmcarr,

I hope you could also help me out

I am having a similar problem here, no idea what is wrong with these reads

Exception processing reads: HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/1 and HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/2
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 58
......

Cheers

[peer.b]

Trimmomatic is among the top ranking trimmers in the recent review. Congrats Tony!

[tonybolger]

Hi kmcarr,

I hope you could also help me out

I am having a similar problem here, no idea what is wrong with these reads

Exception processing reads: HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/1 and HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/2
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 58
......

Cheers

Hi,

Could you tell me the command line used, including the version of trimmomatic, and also the remainder of the stack trace?

Tony.

[luiscunhamx]

Sorry Tony,

not sure why I did not post it in the first place

here goes the command:

java -classpath /media/scratch/sbilnc/appz/Trimmomatic-0.32/trimmomatic-0.32.jar org.usadellab.trimmomatic.TrimmomaticPE -phred33 w2_1_sufx.fastq w2_2_sufx.fastq trimmomatic_w1_1_sufx.fastq trimmomatic_w1_1_sufx_unpaired.fastq trimmomatic_w1_2_sufx.fastq trimmomatic_w1_2_sufx_unpaired.fastq ILLUMINACLIP:/media/scratch/sbilnc/appz/Trimmomatic-0.32/adapters/TruSeq2-PE.fa:2:30:10 LEADING:3 SLIDINGWINDOW:4:15 MINLEN:100

and the rest you can find it in text file attached,


Thanking in advance

[tonybolger]

Sorry Tony,

not sure why I did not post it in the first place.

No problem.

Can you also post the reads:

HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/1 and HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/2

from the input files? It seems they trigger something, and even though it looks like a bug in the trimmomatic (or a least lack of graceful failure), i would like to know the trigger so i can handle it better or survive it.

Thanks,

Tony.

[luiscunhamx]

Hi Tony


Strangely the reads are these

@HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/1
CA
+
CC

and

@HISEQ2000:406:H0JYCADXX:2:1101:13467:8659_/2
G
+
@


I had no idea that I had this type of error as the data were produced by hiseq2500 rapid run and I would expect all reads with 150bp as this is the raw data (and added suffixes), nevertheless do you think would be a good idea to filter by length before feeding it to Trimmomatic?

Thanking in advance for the attention


Luis

[tonybolger]

I had no idea that I had this type of error as the data were produced by hiseq2500 rapid run and I would expect all reads with 150bp as this is the raw data (and added suffixes), nevertheless do you think would be a good idea to filter by length before feeding it to Trimmomatic?

I guess some processing was already applied to the reads, because as you say, the reads should be 150bp each. I normally recommend against using trimmed data if it all possible with Trimmomatic - it was designed to work on the raw output. Perhaps you could contact whoever supplied the data and see if they have the original data also.

In any case, trimmomatic appears to break on such short read pairs - i guess i never tested such a scenario. You could try adding a MINLENGTH filter as the first step, to prevent the short reads causing problems.

Thanks,

Tony.

[luiscunhamx]

Thanks Tony,

I will give it a try

Cheers

[kentnf]

Hi tonybolger,

How about add a function on Trimmomatic to remove the adapter of small RNA. The read is like this:

small RNA + ADAPTER

I just need the reads with adapter sequence. If the read has adapter, clip it. Otherwise, drop it.

Thanks