[jcorn427]

Hi all, I'm hoping you can help me with an issue I'm having. I get a java exception as follows:

Exception in thread "Thread-4" java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 900000

The command I ran was:

java -jar /data/illumina/Trimmomatic-0.30/trimmomatic-0.30.jar PE -threads 12 -phred33 -trimlog r.log 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R1_1.fastq.bz2 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R2_2.fastq.bz2 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R1_1.Qscore.paired.fastq.bz2 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R1_1.Qscore.unpaired.fastq.bz2 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R2_2.Qscore.paired.fastq.bz2 110908_SN388_0270_BC0265ACXX_DNA_1_CGATGT_L003.ft.R2_2.Qscore.unpaired.fastq.bz2 ILLUMINACLIP:/data/illumina/Trimmomatic-0.30/adapters/adapters_list.fa:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:30 MINLEN:36

The version of Trimmomatic I am running is 0.30.
The rest of the log can be found in the attached text file. Thanks so much. If there's anything else you need, let me know.

[westerman]

Try using only one thread. If nothing else that should give an good indication of the input line that is giving the error. As far as I know trimmomatic does not speed up very much with multiple threads. In any case for troubleshooting get rid of that variable.

[jcorn427]

Ok, so, the only modification I made was to change the number of threads to 1 and I re-ran the program. Unfortunately, I'm still getting the same kind of error:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 900000
        at org.itadaki.bzip2.BZip2BlockCompressor.writeRun(BZip2BlockCompressor.java:103)
        at org.itadaki.bzip2.BZip2BlockCompressor.close(BZip2BlockCompressor.java:201)
        at org.itadaki.bzip2.BZip2OutputStream.closeBlock(BZip2OutputStream.java:153)
        at org.itadaki.bzip2.BZip2OutputStream.write(BZip2OutputStream.java:107)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
        at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281)
        at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:124)
        at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
        at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:128)
        at java.io.BufferedWriter.write(BufferedWriter.java:229)
        at java.io.Writer.write(Writer.java:157)
        at org.usadellab.trimmomatic.fastq.FastqSerializer.writeRecord(FastqSerializer.java:63)
        at org.usadellab.trimmomatic.TrimmomaticPE.processSingleThreaded(TrimmomaticPE.java:76)
        at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:275)
        at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:347)
        at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:23)

Any thoughts?

[westerman]

Looks like it is having problems writing bzip files for some reason. Two thoughts:

1) Don't output to .bz format; eliminate that variable in testing.

2) What is does the trimlog r.log tell you. The last line should give the last read processed.

[jcorn427]

Here's the last line from the r.log:

HWI-ST388-W7D:270:C0265ACXX:3:1101:9507:22340 2:N:0:CGATGT 101 0 101 0

However, I changed all of the output files from .bz2 to .gz and there hasn't been an error yet. I think that did it. Thanks!

[jcorn427]

So, that one run completed successfully. I went to run it again on the next set of data and now I get a new exception.

Exception in thread "main" java.lang.NullPointerException
        at org.usadellab.trimmomatic.fastq.FastqParser.parseOne(FastqParser.java:57)
        at org.usadellab.trimmomatic.fastq.FastqParser.next(FastqParser.java:106)
        at org.usadellab.trimmomatic.TrimmomaticPE.processSingleThreaded(TrimmomaticPE.java:56)
        at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:275)
        at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:347)
        at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:23)

Any hints as to what this might be would be great. Thanks for all of your help.

[tonybolger]

So, that one run completed successfully. I went to run it again on the next set of data and now I get a new exception.

Exception in thread "main" java.lang.NullPointerException
        at org.usadellab.trimmomatic.fastq.FastqParser.parseOne(FastqParser.java:57)
        at org.usadellab.trimmomatic.fastq.FastqParser.next(FastqParser.java:106)
        at org.usadellab.trimmomatic.TrimmomaticPE.processSingleThreaded(TrimmomaticPE.java:56)
        at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:275)
        at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:347)
        at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:23)

Any hints as to what this might be would be great. Thanks for all of your help.

Generally this is caused by a partial record (fastq records always come in 4 line groups) at the end of the file. Blank line(s) also may also do it.

[bharat_iyengar]

Is it possible to alter the minimum seed length in trimmomatic.SE, for adapter clipping ?

If it is not explicit which one of the source files has to be edited ?

[shangzhong0619]

How does sliding window work

I was just wondering how does sliding window in trimmomatic work?
The definition is scanning from the 5’ end of the read, and removes the 3’
end of the read when the average quality of a group of bases drops
below a specified threshold.
For example, if we have a sequence ATCGATCGATCG and we set SLIDINGWINDOW: 4:15.
It begins with the first 4 in a window, ATCGATCGATCG, but if the score is below 15, which base it will trim? Is that the last base in this window? What is the next start position of the window? 2 or 5? thanks.

[tonybolger]

I was just wondering how does sliding window in trimmomatic work?
The definition is scanning from the 5’ end of the read, and removes the 3’
end of the read when the average quality of a group of bases drops
below a specified threshold.
For example, if we have a sequence ATCGATCGATCG and we set SLIDINGWINDOW: 4:15.
It begins with the first 4 in a window, ATCGATCGATCG, but if the score is below 15, which base it will trim? Is that the last base in this window? What is the next start position of the window? 2 or 5? thanks.

The sliding window moves by one position each time. So it starts with positions 1-4, if these are ok, then tries positions 2-5.

Once a 'window' falls below the required quality average, all bases beyond that point at removed, as well as any bases from the end of the window which are below the required quality until one of the required quality is found.

This can result in the final trimmed read including none, some or (in very unusual circumstances) all the bases within the failed window - but typically around half the window will be kept.

Hope this helps,

Tony.

[Lays Cruz]

Hi all.
I'm having problems with the trimmomatc outputs, has different numbers of reads in PE files, this should not happen.
Does anyone know what I can do?
Thanks.

[GenoMax]

Hi all.
I'm having problems with the trimmomatc outputs, has different numbers of reads in PE files, this should not happen.
Does anyone know what I can do?
Thanks.

Are you trimming the files together using the PE option?

[Lays Cruz]

Yes. My data is Illumina MiSeq and my command line is as follows:
#java -jar /usr/local/bin/trimmomatic-0.30.jar PE -threads 4 -phred33 ./jatoba/Hst_S2_L001_R1_001.fastq ./jatoba/Hst_S2_L001_R2_001.fastq ./jatoba/fq/Hst_S2_PE_1p.fq ./jatoba/fq/Hst_S2_SR_1p.fq ./jatoba/fq/Hst_S2_PE_2p.fq ./jatoba/fq/Hst_S2_SR_2p.fq LEADING:30 TRAILING:30 SLIDINGWINDOW:4:30 HEADCROP:18 MINLEN:20

Thanks for answers.

[Lays Cruz]

Are you trimming the files together using the PE option?

Yes. My data is from Illumina MiSeq and my command's line is as follows:
#java -jar /usr/local/bin/trimmomatic-0.30.jar PE -threads 4 -phred33 ./jatoba/Hst_S2_L001_R1_001.fastq ./jatoba/Hst_S2_L001_R2_001.fastq ./jatoba/fq/Hst_S2_PE_1p.fq ./jatoba/fq/Hst_S2_SR_1p.fq ./jatoba/fq/Hst_S2_PE_2p.fq ./jatoba/fq/Hst_S2_SR_2p.fq LEADING:30 TRAILING:30 SLIDINGWINDOW:4:30 HEADCROP:18 MINLEN:20

Thanks.

[Brian Bushnell]

Hi all,

I'm testing Trimmomatic's performance on adapter removal, and the results are mysteriously bad. So I'd like to make sure I'm not doing anything wrong. This is my command line (modified from the website):

java -Xmx8g -jar trimmomatic-0.32.jar SE -phred33 dirty.fq tclean.fq ILLUMINACLIP:gruseq.fa:2:30:10

...where dirty.fq is a file containing reads with adapter sequences and gruseq.fa is a file containing the adapter sequences. The adapters are inserted synthetically and the reads are tagged, so I know precisely what the correct results should be, and what I'm getting is not really close. Any suggestions?