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

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

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

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

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

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

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

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]

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]

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.

[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

[luiscunhamx]

Thanks Tony,

I will give it a try

Cheers

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

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]

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.