[helios]

Make trimmomatic a binary/executable

Hi Guys,

in case you prefer to run trimmomatic as binary ./trimmomatic

you can follow these steps:

1) download and gunzip stub.sh.gz (in attachment) where trimmomatic-0.X.jar is located
2) cat stub.sh trimmomatic-0.30.jar >> trimmomatic
3) chmod +x trimmomatic
4) add trimmomatic's home to your path

ref: https://coderwall.com/p/ssuaxa

in case you need to modify java's parameters we must modify stub.sh opportunely.

Ciao.

[mastal]

Introducing the Trimmomatic

This is an extract from the trimmomatic web page:

specifying a trimlog file creates a log of all read trimmings, indicating the following details:

* the read name
* the surviving sequence length
* the location of the first surviving base, aka. the amount trimmed from the start
* the location of the last surviving base in the original read
* the amount trimmed from the end

http://www.usadellab.org/cms/index.php?page=trimmomatic

[leda]

What do the four columns following the read identifier in the trimlog represent? I can't find this in the documentation.

thanks!

[tonybolger]

Yeah, still clear as mud.

Sorry that my explanation for this obviously sucks, and now that the adapter sequences are included directly in trimmomatic, there's probably not such a major need for everyone to understand it, but here goes anyway.

During adapter read-though, with paired end data (and assuming the same length of forward and reverse reads) we get pairs with:

• The forward read consisting of X useful bases, followed by Y bases from the end of the reverse read adapter.
• The reverse read consisting of X useful bases, followed by Y bases from the end of the forward read adapter.

The beauty is that those X bases in both the forward and reverse reads, are the same bases, though in reverse complement, and those Y bases are always specific known sequences starting immediately afterwards. So rather than fish for those Y bases in isolation (which is risky / difficult if Y is small), we can check simultaneously for 3 things:

• The first X bases of both reads being reverse complements of each other.
• The additional bases from the forward read match the reverse adapter.
• The additional bases from the reverse read match the forward adapter.

Since all three must be found to support the 'read-though' hypothesis in a given read pair/position, the false positive rate is very low. Naturally we don't know what X is, but we can check every possible X from zero to the read length.

[tonybolger]

I have two adapter sequences of 58 bp and 66 bp that I would like to remove from my Illumina data set (if present). Can Trimmomatic recognise partial matches to these adapter sequences? For example, if I am using 100 bp reads and a particular sequence contains 90 bp of DNA from the source organism, the remaining 10 bp at the end of the read might be from the adapter. Would Trimmomatic be able to pick this up? Or must it find a match to the whole adapter sequence?

In the case of paired-end data with adapter 'read-though' (where the DNA fragment is less than the read length, and the end of the reads are from the 'opposite' adapter), trimmomatic can remove even a single adapter base (if you use sufficiently aggressive settings). Older versions of trimmomatic required at least 8 bp of adapter in this case, but that was probably too conservative so i reduced it. The latest versions also include the recommended adapter sequences, which have been a common stumbling point.

For other, less common, scenarios, where the adapter location/orientation isn't known in advance, or where you're using single end data, you'd typically want to be a bit more cautious, but 10bp or greater can usually be removed at a reasonable false positive rate.

Hope this helps.

[cllorens]

Maybe you can also check out cutadapt, that it is also useful for illumina data.

http://code.google.com/p/cutadapt/

[claire.anderson1]

How does adapter trimming in Trimmomatic work?

I have two adapter sequences of 58 bp and 66 bp that I would like to remove from my Illumina data set (if present). Can Trimmomatic recognise partial matches to these adapter sequences? For example, if I am using 100 bp reads and a particular sequence contains 90 bp of DNA from the source organism, the remaining 10 bp at the end of the read might be from the adapter. Would Trimmomatic be able to pick this up? Or must it find a match to the whole adapter sequence?

I'm new at playing with NGS data, so any advice would be gratefully received!

[kmcarr]

Here is the answer, for me was useful:

Simple clipping is just finding a contaminant sequence somewhere within a read. Conceptually, you get contaminant and read, and you slide them across each other, until you get a perfect or close enough match. So, with R being read bases, and C being contaminant, you check

1)
RRRRRRRRRRR
CCCC

2)
RRRRRRRRRRR
CCCC ->

etc.

Palindrome clipping is a bit more complex - and related to actual palindromes only in a twisted mind like mine. In this case, you 'ligate' the presumed adapter sequence to the start of each read in a pair, and try sliding them over each other.

So with F being bases from the forward read, R being bases from the reverse read, and A being either adapter (technically the two adapters are different, but lets ignore that for now).

AAAAAAFFFFFFF ->
<- RRRRRRRAAAAAA

In this case, the aligning region is much longer, since it consists of the entire read length plus part of the adapter. This gives a very high confidence that an apparent 'read-though' is a true-positive.

Yeah, still clear as mud.

[alisrpp]

Thansk for the answers!

About the palindrome clipping, some days ago i wrote one of the creators of Trimmomatic asking about an alternative explanation to the one in the web site (i couldn't understand it either).
Here is the answer, for me was useful:

Simple clipping is just finding a contaminant sequence somewhere within a read. Conceptually, you get contaminant and read, and you slide them across each other, until you get a perfect or close enough match. So, with R being read bases, and C being contaminant, you check

1)
RRRRRRRRRRR
CCCC

2)
RRRRRRRRRRR
CCCC ->

etc.

Palindrome clipping is a bit more complex - and related to actual palindromes only in a twisted mind like mine. In this case, you 'ligate' the presumed adapter sequence to the start of each read in a pair, and try sliding them over each other.

So with F being bases from the forward read, R being bases from the reverse read, and A being either adapter (technically the two adapters are different, but lets ignore that for now).

AAAAAAFFFFFFF ->
<- RRRRRRRAAAAAA

In this case, the aligning region is much longer, since it consists of the entire read length plus part of the adapter. This gives a very high confidence that an apparent 'read-though' is a true-positive.

[kmcarr]

Thanks a lot!!!

Do you recommend me to do an individual FASTA file for each index?

No, I use a single file with all of the Illumina TruSeq sequences in it. I also don't bother designating any of them for "Palindrome" search. I've read the description of Palindrome search several times on the Trimmomatic site and frankly still don't understand it. I just do simple searches for them and it seems to work fine for me.

I have attached the file I use with Trimmomatic.

[westerman]

All my adapters are in one file. Given the number of adapters I can not see it working otherwise. I undoubtedly over process my sequences by looking at both strands in both directions with all possible adapters -- as kmcarr says, "inefficient" -- but it makes me more comfortable that I am picking up everything.

[alisrpp]

Thanks a lot!!!

Do you recommend me to do an individual FASTA file for each index?

[westerman]

Your adapter fasta files have /2 after the IDs of the index adapters which tells Trimmomatic to only check these sequences against the second (reverse) read. ...

Ah, good catch! All my adapters are non-strand specific with reverse-complements thus I just skipped over that part of his adapters. It is undoubtedly the correct solution.

[westerman]

Ok, having gotten the possible script problem out of the way, everything else looks syntactically correct. Time to dig into the adapter file or the actual reads that are not being properly trimmed. It is possible that the 2:40:15 parameter to the ILLUMINACLIP is tripping you up. Are you using the simple trim or the, in my experience more rare, palindrome trim? You say:

i'm still having some overrepresented sequences that the fastQC recognize as one of the Illumina indexes.

What are these sequences?

Can you look at a handful of reads reported to have illumina indexes and manually see if they have the index. And, if so, how good is the match?

[kmcarr]

Your adapter fasta files have /2 after the IDs of the index adapters which tells Trimmomatic to only check these sequences against the second (reverse) read. These adapters will show up in the first (forward) read, not the second. Likewise the universal adapter sequence will show up in the second read, not the first. You need to swap the /1 and /2 endings in your adapter FASTA files and you should use the reverse complement of the Universal adapter. You could remove /1 and /2 entirely forcing Trimmomatic to check the adapters against all reads but that is inefficient.