[Rammaria]

Trimmomatic bad parallelize

I'm sorry, I have created a new thread.

[tonybolger]

For what it's worth I hit this exception running with a file that turned out to have a corrupted line...perhaps a more informative error is possible.

Interesting - seems that file has very long lines (or is missing newlines entirely). I agree the error message should be more informative.

[tonybolger]

Tony, Slightly off-topic perhaps, but shouldn't it be possible to automatically detect things like adapters and have a fully automatic trim process? It seems like this would save quite a bit of hassle in obtaining adapter sequences, studying FastQC output, playing with the many parameters, things like that.

Good idea - it would take a bit of work, but in principle it can be done.

[tonybolger]

Hi everyone,

I am a newbie in NGS. I have a data sequenced with Illumina Truseq Kit from Hiseq System. I am trying to trim the adapters in my data with Trimmomatic but not sure on which adapters fasta files to choose (TruSeq3-PE.fasta or TruSeq3-PE-2.fasta ?).

Could anyone please explain to me what's the difference between these two files ?

TruSeq3-PE.fasta
TruSeq3-PE-2.fasta

Thanks a lot ^^

With good quality library preps, TruSeq3-PE should be enough and will run much faster (since it checks only for the most common contamination scenario).

For 'strange' situations, e.g. libraries with double-ligated adapters, partly degraded adapters or other issues, 'TruSeq3-PE-2' does a better job. For high quality libraries though, the extra processing time needed is probably not worth it.

[tonybolger]

Hi, I found trimmomatic very useful.
And it works well with my Hiseq data using Nextera PE adaptor in single end mode.
But I found the output is quite strange in paired end mode:

My output after trimming:
Input Read Pairs: 12484647 Both Surviving: 4943420 (39.60%) Forward Only Surviving: 7297375 (58.45%) Reverse Only Surviving: 16245 (0.13%) Dropped: 227607 (1.82%)

It seems that the forward and reverse reads after trimming is very unbalanced.
What would cause this?
Thanks.

Most likely (especially since you are using a nextera prep), you have a lot of short fragments which have adapter read-through (the read length > the insert length). Since the trimmed read pairs are therefore merely reverse-complements of each other (both contain the full fragment), the reverse read adds little information, and thus the default behaviour of trimmomatic is to drop the reverse read. You can choose to keep the reverse read by adding an extra 'true' parameter to the ILLUMINACLIP step.

[jcyh]

Hi everyone,

I am a newbie in NGS. I have a data sequenced with Illumina Truseq Kit from Hiseq System. I am trying to trim the adapters in my data with Trimmomatic but not sure on which adapters fasta files to choose (TruSeq3-PE.fasta or TruSeq3-PE-2.fasta ?).

Could anyone please explain to me what's the difference between these two files ?

TruSeq3-PE.fasta
TruSeq3-PE-2.fasta

Thanks a lot ^^

[Will Nelson]

For what it's worth I hit this exception running with a file that turned out to have a corrupted line...perhaps a more informative error is possible:

java -Xmx4096m -jar /data/agcol/databases/mouse/paper_rerun/ext/Trimmomatic-0.32/trimmomatic-0.32.jar PE -threads 1 -trimlog trim1.log test1.fq test2.fq Out1.fastq Sing1.fastq Out2.fastq Sing2.fastq CROP:95 HEADCROP:5
TrimmomaticPE: Started with arguments: -threads 1 -trimlog trim1.log test1.fq test2.fq Out1.fastq Sing1.fastq Out2.fastq Sing2.fastq CROP:95 HEADCROP:5
Quality encoding detected as phred33
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515)
at java.lang.StringBuffer.append(StringBuffer.java:306)
at java.io.BufferedReader.readLine(BufferedReader.java:345)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.usadellab.trimmomatic.fastq.FastqParser.parseOne(FastqParser.java:72)
at org.usadellab.trimmomatic.fastq.FastqParser.next(FastqParser.java:171)
at org.usadellab.trimmomatic.TrimmomaticPE.processSingleThreaded(TrimmomaticPE.java:57)
at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:293)
at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:498)
at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:35)

[Will Nelson]

why not automatic mode?

Tony, Slightly off-topic perhaps, but shouldn't it be possible to automatically detect things like adapters and have a fully automatic trim process? It seems like this would save quite a bit of hassle in obtaining adapter sequences, studying FastQC output, playing with the many parameters, things like that.

[Mchicken]

Thanks for your reply Tony, now I can incorporate Trimmomatic without compunction into my pipeline

[tonybolger]

So can anyone tell me where i am wrong?

Trimmomatic uses a slightly more complex strategy, so in some cases (if the quality around the trim point looks like a "U"), trimmomatic doesn't do what you expect.

Consider a typical monotonic dropping quality - first you might want to decide where the window drops below the threshold, then remove the later, weaker bases within the window, but keep the earlier, stronger ones. To achieve this, you need to first find the window, then decide how much to keep.

Once the window is found (very likely in the position you expect), the individual bases are checked against the required quality from the end of the window backwards. In your example, the last base is somewhat stronger than the threshold, so removal stops there.

An obvious alternative would be to start at the beginning of the window, and cut at the first weak base. When i compared the two approaches, the 'from the back' approach seemed to work better, so trimmomatic uses this.

Hope this helps,

Tony.

[Mchicken]

Hey guys,
i`ve got some problems with Trimmomatic:

I have the following 100bp long read:

@HWI-ST365:34625ECACXX:5:1101:3183:2046 1:N:0:TGACCA
NCAGGGGGAACAGGCTGATCTCCCCCAAGAGTCCACATCGACGGGGAGGTTTGGCACCTCGATGTCGGCTCATCGCAACCTGGGGCGGAAGGACGTCCCC
+
#11A?DDDHHBBF?FHBGCGHGGDD@FFDDD9B@FHD8)<FHIG8B89>(,5,5(::<CB?'9@BC8;5?##############################

I only run SLIDINGWINDOW:4:15 on this read

and what i get is:

Log-File:

HWI-ST365:34625ECACXX:5:1101:3183:2046 1:N:0:TGACCA 52 0 52 48

trimmed fastq:

@HWI-ST365:34625ECACXX:5:1101:3183:2046 1:N:0:TGACCA
NCAGGGGGAACAGGCTGATCTCCCCCAAGAGTCCACATCGACGGGGAGGTTT
+
#11A?DDDHHBBF?FHBGCGHGGDD@FFDDD9B@FHD8)<FHIG8B89>(,5


But when i run my own script on the read i can see that the pattern (,5, beginning at position 50 has an average quality of 12.25, which is below the required 15. So the read should survive from position 1 to 49 and not until position 52 as determined by Trimmomatic.

So can anyone tell me where i am wrong?

Thanks
Mchicken

[tonybolger]

Hi, back again. When I use trimmomatic I get abnormally high Kmer reads on FastQC, I read out the Kmers and realized that most of my forward adapter was still inside of my cDNA.

I opened the TruSeq2 adapter file and realized that the Prefix PE/1 adapter (I guess that means the forward adapter?) Didn't match the forward adapter I was using, which is:
TruSeq Adapter, Index 2
5’ GATCGGAAGAGCACACGTCTGAACTCCAGTCACCGATGTATCTCGTATGCCGTCTTCTGCTTG

This sequence looks like a TruSeq-3 adapter - if so, either the TruSeq3-PE or TruSeq3-PE-2 adapter files should remove the sequencing adapters. The useful part of the reads should survive if they the adapters are in the normal position.

If you do have any surviving adapters, can you post a few examples?

Thanks,

Tony.

[kevluv93]

Hi, back again. When I use trimmomatic I get abnormally high Kmer reads on FastQC, I read out the Kmers and realized that most of my forward adapter was still inside of my cDNA.

I opened the TruSeq2 adapter file and realized that the Prefix PE/1 adapter (I guess that means the forward adapter?) Didn't match the forward adapter I was using, which is:
TruSeq Adapter, Index 2
5’ GATCGGAAGAGCACACGTCTGAACTCCAGTCACCGATGTATCTCGTATGCCGTCTTCTGCTTG

So I went in and replaced the default forward adapter with the sequence you see above.

Now I have another issue, for some reason trimmomatic has managed to cut 8GB of data into 2GB of data. (if I combine the forward and reverse paired and unpaired files) Fastqc is giving me Kmers that are similar to my sequence, and when I opened the forward paired file I saw that fairly large chunks of my primers are still at the 3' end of my cDNA.

ex.
GATCGGAAGAGCACACGTCTGAACTCCAGTCAC
GATCGGAAGAGCACACGTCTGAACTCC
ATCGGAAGAGCACACGTCTGAACTCCAGTCACCGA

They're just small enough for trimmomatic to miss. Is there any helpful suggestions you can give me regarding the settings of trimmomatic to help me cut these small bits of adapters off the end of my reads? Is there a reason why only small fragments of my adapter sequences would be left after using trimmomatic? Finally, is it usual for such a large portion of data to get cut when using trimmomatic or am I screwing this up? (8GB to 2GB of data)

[BFM]

Hi i have used trimmomtaic to clip the adapter sequences. Yet i am still having a problem with kmers, sequence per base content. My question is how do we improve the quality if there is any failure in Fastqc results????

[usad]

great that it works now.