[tonybolger]

Yup, the complete record is:

@FCB01CWABXX:1:2205:1823:145892
GAGGTTCTTTGCTTCCTTCGGGAACCTCTCCAGCCCCACTGCCATCCTTGGCAACCCCATGGTCCGTGCCCATGGCAAGAAAGTGCTCAC
+FCB01CWABXX:1:2205:1823:145892
ggggggggggggfeggggggggcgggeggggggggeggg18207:146312

This looks indeed like a dodgy record - the end of the quality score line is missing, and the numeric bit looks like the end of the name from another record.

I suppose I could just cut this record out?

Perhaps, but i would be rather concerned where it came from. Furthermore, you probably then end up with additional missing records, and you would need to match the other 'paired' file in the dataset.

Interestingly, if I leave out the ILLUMINACLIP:TruSeqForTrimmomatic.fna:2:30:10 option, and leave my code as:

trimmomatic paired-end -phred64 -trimlog trimlog SRR522907_1.fastq SRR522907_2.fastq paired_output1b.fastq unpaired_output1b.fastq paired_output2b.fastq unpaired_output2b.fastq LEADING:20 TRAILING:20 MINLEN:30

I get files that I CAN run through fastqc without any problems (the results don't look great, but I can run the files through). Does that set off any red flags?

This is also very strange. Trimmomatic parses the FASTQ in the same way regardless of the trimming steps selected, so for some reason, it must have seen valid records this time (or at least records which aren't broken in this way).

I suggest running something like md5sum on the original files on this computer, and on a separate machine, a few times each, to see if there is any inconsistency.

[rmdoyle]

Hi tonybolger,

Thanks for your help with this, I ended up removing the offensive record and the corresponding paired read. I don't know that this was causing the original problem with corrupted files, but the issue seems to have resolved itself...

[fishie]

Hi. Sorry I'm generally new to this forum and NGS.

I'm looking at using trimmomatic to remove adapters and trim my sequences from MiSeq. I used the Nextera XT kit and their primers for my libraries, not the TruSeq kits. Does anyone know if a list of the Nextera adapater and primer sequences is readily available somewhere for use with ILLUMINACLIP?

[fishie]

per my above question... I did find the Nextera XT adapater sequences, and I understand how to use them for simple clipping for trimmomatic. However, I'm still unclear on exactly what the palindrome clipping is, and whether it is necessary for my MiSeq data (paired reads, 2x250. Note that it is NOT a mate-pair library though). If it is suggested to use palindrome clipping, what should be used for the prefixes?

[htetre]

Hello,

I am trying to use Trimmomatic for the first time and am getting the following error message:

TrimmomaticPE: Started with arguments: -phred33 /homes/htetre/Illumina06272013/ANN_ACAGTG_L004_R1_001.fastq /homes/htetre/Illumina06272013/ANN_ACAGTG_L004_R2_001.fastq ANN_1_PE.fastq ANN_1_UP.fastq ANN_2_PE.fastq ANN_2_UP.fastq ILLUMINACLIP:/homes/htetre/Trimmomatic-0.30/adapters/TruSeq2-PE.fa

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at org.usadellab.trimmomatic.trim.IlluminaClippingTrimmer.makeIlluminaClippingTrimmer(IlluminaClippingTrimmer.java:53)
at org.usadellab.trimmomatic.trim.TrimmerFactory.makeTrimmer(TrimmerFactory.java:27)
at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:344)
at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:23)

Can someone help me with this error message?

Thank you so much for your help
Hannah

[westerman]

I suspect something wrong with your input files. Could you head and tail 5 lines from each of the files and post it to this forum thread.

[htetre]

Below is the head and tail of my file.

Thanks for taking a look.

HEAD:
ANN_ACAGTG_L004_R1_001.fastq <==
@HWI-ST538:334:C225RACXX:4:1101:1202:1954 1:Y:0:ACAGTG
ACNTTATGATTTTTGGNNNGTNCNANGNNCAGNGCGGNGCGGGGNNNNNNNNGNAACATAATANNNNNNNNNNNCATGAT AAAAATGNATAACACNCAAT
+
<<#25>?@<<@@????################################################################ ####################

TAIL:
<=7?A><@A+?AB<BBB3A<<@<ABB@BA<;?A7=A>B90?=:??A><4=*('--=(.8>BBA.7>AAA###############################
@HWI-ST538:334:C225RACXX:4:2316:21264:100116 1:Y:0:ACAGTG
TTGTTCTGTCGTAATCTTCAAACGAAGCAATTTGTTTTACCGGAATCCAATTTACCCATATCAACTCCTCGAACGCATTCAAAGTGCTCGACTGAAGCAA
+
(5;=?@<@.)@(2<5>8):=8:<35@=(<1@#####################################################################

[tonybolger]

Hello,

I am trying to use Trimmomatic for the first time and am getting the following error message:

TrimmomaticPE: Started with arguments: -phred33 /homes/htetre/Illumina06272013/ANN_ACAGTG_L004_R1_001.fastq /homes/htetre/Illumina06272013/ANN_ACAGTG_L004_R2_001.fastq ANN_1_PE.fastq ANN_1_UP.fastq ANN_2_PE.fastq ANN_2_UP.fastq ILLUMINACLIP:/homes/htetre/Trimmomatic-0.30/adapters/TruSeq2-PE.fa

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at org.usadellab.trimmomatic.trim.IlluminaClippingTrimmer.makeIlluminaClippingTrimmer(IlluminaClippingTrimmer.java:53)

Hi Hannah,

It appears you're missing the numeric thresholds used with the ILUMINACLIP step. If you use the suggested values, that step should look like:

ILLUMINACLIP:/homes/htetre/Trimmomatic-0.30/adapters/TruSeq2-PE.fa:2:30:12

I really need to improve the error reporting when such problems occur.

Tony.

[ebioman]

Question regarding Paired/Unpaired Output

I have a question regarding the output files if trimming of paired-ends is chosen.
To recapitulate:
4 files are generated:

• R1_Paired
• R1_Unpaired
• R2_Paired
• R2_Unpaired

I am confused of the final data these contain and find the manual less helpful.

E.g. I did a trimming and I analyze with fastqc the original file R1 and R1_Paired. This reports to me that the quality enhanced and I can observe that certain bad reads were discarded.

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 ?

I hope somebody can help solve some of these question

[tonybolger]

What does R1_Unpaired contain ?

The forward reads for which the corresponding reverse read was discarded, for whatever reason. The reason behind this is how most tools interpret paired files - tools often assume that both files contain corresponding reads in the same order. Thus you need somewhere else to put 'singleton' reads which have lost their mate.

Do I use R1_unpaired as well for the assembly or only R1_paired?

If the assembler (or other downstream tool) can handle a mix of paired and single end reads, you can use both.

In the case when no R1_paired is generated, do I use directly R1_unpaired or does this indicate a serious problem ?

This seems strange - 4 files should always be created (when running trimmomatic in paired-end mode).

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

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

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

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

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