[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]

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.

[peer.b]

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

[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

[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.

[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]

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]

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]

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

[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.

[debarryj]

This bug, which should be fixed in the current version, is triggered when a read pair have a big difference in length between the forward and reverse reads - this was rare, since typically the tool worked on untrimmed data, with equal forward and reverse read lengths.

Incidentally, it appears you have enabled the miseq built-in trimming - this prevents the correct detection of adapter read-through by trimmomatic, so i typically would not suggest using both.

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.

Best

[tonybolger]

Greetings and thanks for the great tool!
I am attempting to run Trimmomatic on MiSeq data and the error I am getting is not showing up in internet searches etc. Any help would be appreciated.

This bug, which should be fixed in the current version, is triggered when a read pair have a big difference in length between the forward and reverse reads - this was rare, since typically the tool worked on untrimmed data, with equal forward and reverse read lengths.

Incidentally, it appears you have enabled the miseq built-in trimming - this prevents the correct detection of adapter read-through by trimmomatic, so i typically would not suggest using both.

[debarryj]

Greetings and thanks for the great tool!
I am attempting to run Trimmomatic on MiSeq data and the error I am getting is not showing up in internet searches etc. Any help would be appreciated.

I have used FASTQC to check the data and select Trimmomatic parameters. The process dies quickly with the following contents in the error file:

"TrimmomaticPE: Started with arguments: -threads 1 -phred33 -trimlog TRIMlogFILE Agar1943_S1_L001_R1_001-1.fastq Agar1943_S1_L001_R2_001-1.fastq R1_paired R1_unpaired R2_paired R2_unpaired ILLUMINACLIP:adapters.fasta:2:40:15 LEADING:32 TRAILING:32 SLIDINGWINDOW:4:32 MINLEN:150
Using PrefixPair: 'TACACTCTTTCCCTACACGACGCTCTTCCGATCT' and 'GTGACTGGAGTTCAGACGTGTGCTCTTCCGATCT'
ILLUMINACLIP: Using 1 prefix pairs, 0 forward/reverse sequences, 0 forward only sequences, 0 reverse only sequences
Exception processing reads: M00313:59:000000000-A3E75:1:1101:16432:1530 1:N:0:1 and M00313:59:000000000-A3E75:1:1101:16432:1530 2:N:0:1
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 54
at org.usadellab.trimmomatic.fastq.trim.IlluminaClippingTrimmer.palindromeReadsCompare(IlluminaClippingTrimmer.java:383)
at org.usadellab.trimmomatic.fastq.trim.IlluminaClippingTrimmer.processRecords(IlluminaClippingTrimmer.java:184)
at org.usadellab.trimmomatic.TrimmomaticPE.processSingleThreaded(TrimmomaticPE.java:66)
at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:278)
at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:350)
at org.usadellab.trimmomatic.TrimmomaticPE.main(TrimmomaticPE.java:358)

real 0m1.568s
user 0m0.421s
sys 0m0.112s"

I have symbolic links to the adapter and input files.

Here are the first 5 lines of the input files:
$ head -n 5 Agar1943_S1_L001_R1_001-1.fastq
@M00313:59:000000000-A3E75:1:1101:17309:1456 1:N:0:1
CTCCGCTNCGCTCTGTAACTGTGAGGTTTGTGTTGCGGGAACTTAGTATTTTCCTCCTGCGTTTTTATTATGCCATGGAATGATCAGGTAATATTCCTCTGTGATGCTCTGGCCAGGGACTGCTATGAGTCCTTCGGCCATTAGAAAATTCTGTGGCATTTTAGGCAAT
+
?AAAAAA#>>>AF1FGBGGEDAFDFGABFAFGFGGBEACEGFFFHFAFGHH2DEAGGHFFA/BEFGHBGGHGBEGHGFHFHHGBGHHHEFHHHHHFFGHHHHHGHHGFFHGFHHGEHECFHFGHH2EEEF1GHHGAECG@GFHBFGHEHHHGGHHFFHBBD1FGBGFHG
@M00313:59:000000000-A3E75:1:1101:17278:1456 1:N:0:1

$ head -n 5 Agar1943_S1_L001_R2_001-1.fastq
@M00313:59:000000000-A3E75:1:1101:17309:1456 2:N:0:1
NTTGCCTAAAATGCCACAGAATTTTCTAATGGCCGAAGGACTCATAGCAGTCCCTGGCCAGAGCATCACAGAGGAATATTACCTGATCATTCCATGGCATAATAAAAACGCAGGAGGAAAATACTAAGTTCCCGCAACACAAACCTCACAGTTACAGAGCGGAGCGGAGAGATCGGAAGAGCGTCGTGTAGGGAAAGAGCGTAGATCTCGGTGGTCGCCGTATCATTACAAAAAAAACACACCTATTATCC
+
#>>>AAFFFFFFGGGGGGGG1FHE3FHGFHHGHFCGGGGHACEGHHFHHFA1FHFGAGEBAB/BGFH1FGAGHGGGHHB2GHHHHHHHHHHHBFGFHHHDHHFHHHHH?EGGG?FGGGFFHHHHHFH1>>FHH/E//BGFGAGHGHHHHHEFGHHBFBGB//@C@-CC-AEEFGHCFEGHHHGCCA9EE990E/.9.CF/:;E@FBFFF?E--;-9@@?@;99F/FFB/;BBFF@?--9----/9///9//
@M00313:59:000000000-A3E75:1:1101:17278:1456 2:N:0:1

Here are the 2 reads mentioned in the error output:
@M00313:59:000000000-A3E75:1:1101:16432:1530 1:N:0:1
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+
###################################

@M00313:59:000000000-A3E75:1:1101:16432:1530 2:N:0:1
AGAACGGCAGACCGTCGAGTAGGGAAAGAGCGAAGATTTCGGTGGCCGCCGTATCATTAAAAAAAACTCAACAATCACATTCCCTTTTTATAGCCAGACTTCTCCTTCAACCTCCCCTCCTATTAATTATTCCATAATTATTTCATCTAACCCAATCCTGTTATGCTCAATCTCATGACACACATCACTTCATCCCTTAACTTTTCATCCTCTACATGCAACACACTACTCTAAAATATACATCACGCATT
+

[ebioman]

Thanks for the fast replies !

The sequence which was that bad, giving only an unpaired output, was indeed not the best one.
In this case I have several short paired Illumina reads and 2 long mate-pair reads - one of them being less good. I guess I wont process the mate-pair reads and use them like that exclusively for the scaffolding process and not for contig-assembly. That should be not so bad.

I wonder still whether I should just discard the unpaired information of the short reads or add them to the SOAPdenovo assembly as well ...

[dpryan]

1. What does R1_Unpaired contain ?
2. Do I use R1_unpaired as well for the assembly or only R1_paired?
3. In the case when no R1_paired is generated, do I use directly R1_unpaired or does this indicate a serious problem ?

When paired-end reads are trimmed, it can happen that one read of the pair is such low quality that it's discarded all together, or that it's simply trimmed such that it's too short for further use (i.e., it's length is below some threshold). In those cases, it's mate is moved to the R1_Unpaired file (or R2_Unpaired, though that's less typical), since it lost its paired read. If all of your reads end up unpaired, that suggests that either something went wrong in sequencing or you specified parameters incorrectly. I would assume that single-end reads are still usable for assembly, but that's not something I'm versed in so others would be better qualified to answer that.