SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



Similar Threads
Thread Thread Starter Forum Replies Last Post
Trimmomatic quality trimming kga1978 Bioinformatics 27 09-21-2020 03:00 PM
Trimmomatic error while executing Irina Pulyakhina Bioinformatics 15 07-03-2015 04:44 AM
Problem with trimmomatic amango Bioinformatics 9 12-29-2013 08:43 AM
Introducing pBWA [Parallel BWA] dp05yk Bioinformatics 52 05-21-2013 10:27 PM
Introducing our Ion Torrent! nickloman Ion Torrent 34 05-26-2011 05:56 PM

Reply
 
Thread Tools
Old 06-25-2014, 02:58 AM   #121
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by Mchicken View Post
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.
tonybolger is offline   Reply With Quote
Old 06-25-2014, 03:51 AM   #122
Mchicken
Member
 
Location: Germany

Join Date: Jan 2014
Posts: 39
Default

Thanks for your reply Tony, now I can incorporate Trimmomatic without compunction into my pipeline
Mchicken is offline   Reply With Quote
Old 07-29-2014, 01:10 PM   #123
Will Nelson
Member
 
Location: Arizona

Join Date: Nov 2010
Posts: 16
Default 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.
Will Nelson is offline   Reply With Quote
Old 07-29-2014, 03:08 PM   #124
Will Nelson
Member
 
Location: Arizona

Join Date: Nov 2010
Posts: 16
Default

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 is offline   Reply With Quote
Old 08-18-2014, 07:03 AM   #125
jcyh
Junior Member
 
Location: Malaysia

Join Date: Aug 2013
Posts: 1
Default

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 ^^
jcyh is offline   Reply With Quote
Old 08-19-2014, 12:25 AM   #126
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by tsangkl View Post
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.
tonybolger is offline   Reply With Quote
Old 08-19-2014, 12:28 AM   #127
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by jcyh View Post
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 is offline   Reply With Quote
Old 08-19-2014, 12:34 AM   #128
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by Will Nelson View Post
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 is offline   Reply With Quote
Old 08-19-2014, 12:36 AM   #129
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by Will Nelson View Post
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 is offline   Reply With Quote
Old 09-08-2014, 09:49 AM   #130
Rammaria
Junior Member
 
Location: Moscow, Russia

Join Date: Nov 2013
Posts: 7
Default Trimmomatic bad parallelize

I'm sorry, I have created a new thread.
Rammaria is offline   Reply With Quote
Old 10-30-2014, 02:37 PM   #131
rufessor
Junior Member
 
Location: Salt Lake City

Join Date: Oct 2014
Posts: 5
Default

I am just starting to use Trimomatic on a SE read set from a HiSeq lane-

Here is the command I ran

nohup nice -n 10 java -jar ~/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLOG 11145X1_141017_D00294_0137_AC5N9DANXX_3.txt 11145X1AdapterTRIMout.txt ILLUMINACLIP:/home/user/Trimmomatic-0.32/adapters/TruSeq3-SE.fa:2:30:7 LEADING:3 TRAILING:3 > X1Trim_logfile &

My question is related to this. I was watching the system status after I started this program and noted that I had a couple processes running at maybe 90 and 150% cpu... three cores.

Then I looked further down the process log and see about 40 like this... (see below)
And note that the cache was basically down to zero on the system (there was free memory but the cache was filled).... This is a single lane 50 bp data set from Illumina.... so its not something odd. The job finished in about 4 hours, and seems to have worked perfectly. Just curious what the story behind that monster list of sleeping processes is... if you could provide a bit of detail so that I can understand the consequences of this on other running jobs or ability to start other high load jobs I would feel better.
This server is 64 core >TB memory- thus my need to figure out for myself (I am no sysadmin) whats going on here.

I assume its reflecting in some way the way its multithreaded and these are some kinda feeder process train.... but maybe thats wrong too.... just curious if this is supposed to happen and what it is.

51839 user 30 10 35.2G 10208M 10908 S 3.0 2.0 0:42.10 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51838 user 30 10 35.2G 10208M 10908 S 3.0 2.0 0:42.14 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51837 user 30 10 35.2G 10208M 10908 S 3.0 2.0 0:44.30 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51834 user 30 10 35.2G 10208M 10908 S 2.0 2.0 0:33.67 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51835 user 30 10 35.2G 10208M 10908 S 3.0 2.0 0:46.21 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51787 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.72 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51788 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.03 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51796user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.93 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51807 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.00 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51822 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.47 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51799 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.25 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51782 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.20 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51810 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.00 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51820 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.22 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51812 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.20 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51808 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.28 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51790 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.63 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51817 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.04 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51818 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:04.77 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51793 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.55 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIMLO
51791 user 30 10 35.2G 10208M 10908 S 0.0 2.0 0:03.51 java -jar /home/user/Trimmomatic-0.32/trimmomatic-0.32.jar SE -threads 3 -trimlog trimmomaticX1TRIM

Last edited by rufessor; 10-30-2014 at 07:54 PM.
rufessor is offline   Reply With Quote
Old 10-31-2014, 05:12 AM   #132
atarrant_notspam
Junior Member
 
Location: usa

Join Date: Oct 2014
Posts: 2
Default

I've used Trimmomatic successfully in the past, but I'm now getting an error I don't understand (and haven't been able to find through searches of this forum and google searches).

My command:
java -jar ~/hostshare/trimmomatic-0.32.jar PE -phred33 -trimlog ~/hostshare/trimtest.log ~/hostshare/C2_l.fastq.gz ~/hostshare/C2_r.fastq.gz ~/hostshare/C2_l_pairtrim.fastq.gz ~/hostshare/C2_l_uptrim.fastq.gz ~/hostshare/C2_r_pairtrim.fastq.gz ~/hostshare/C2_r_uptrim.fastq.gz ILLUMINACLIP:NRC_trim_C2.fa:2:40:15 LEADING:20 TRAILING:20 MINLEN:50

I've also tried the "classpath" route and various other permutations.

The output:

[First it reports the adaptors, e.g., Using Long Clipping Sequence: 'GAT....GCTTG'
There are 7 sequences reported, the ones that are present in my fasta file. The remaining output follows]

ILLUMINACLIP: Using 0 prefix pairs, 6 forward/reverse sequences, 1 forward only sequences, 0 reverse only sequences
Exception in thread "main" java.lang.RuntimeException: Unknown trimmer:
at org.usadellab.trimmomatic.trim.TrimmerFactory.makeTrimmer(TrimmerFactory.java:60)
at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:495)
at org.usadellab.trimmomatic.Trimmomatic.main(Trimmomatic.java:35)

Any help really appreciated. I've reached the end of my abilities here.
Also I really tried to figure out this answer, so if someone could point out a resource I should have checked, I will certainly learn from the mistake.
atarrant_notspam is offline   Reply With Quote
Old 10-31-2014, 08:11 AM   #133
rufessor
Junior Member
 
Location: Salt Lake City

Join Date: Oct 2014
Posts: 5
Default

new to this program as well... but when I see this error- at least the text

Quote:
Exception in thread "main" java.lang.RuntimeException: Unknown trimmer:
it has been because I misspelled the actual command (e.g. ILUMINACLIP... not ILLUMINACLIP). You did not, but it makes me wonder if you have an extra space or extra file in there prior to the ILLUMINACLIP statement- that might cause trimmomatic to parse a file name as a command, which would yield this error- I surmise.

Just a guess... but may stimulate you to look again and see something your missing.
rufessor is offline   Reply With Quote
Old 10-31-2014, 08:24 AM   #134
atarrant_notspam
Junior Member
 
Location: usa

Join Date: Oct 2014
Posts: 2
Default

Thank you so much for your help rufessor. You definitely pointed me in the right direction. Using vi I was able to see (and remove) a hidden windows "^M". Rookie mistake, but hopefully someone else can learn from it...
atarrant_notspam is offline   Reply With Quote
Old 10-31-2014, 08:30 PM   #135
rufessor
Junior Member
 
Location: Salt Lake City

Join Date: Oct 2014
Posts: 5
Default

Glad it helped- and happy to hear your crusin along.

I may be answering in part my question- or at least clarifying my question.
I am no longer certain that the sleeping process list actually really effectively did anything to the cache- its almost always used to capacity by linux so I guess my question is-

what the heck are those 40 + sleeping processes doing- and are they effectively actually consuming any resource whatsoever. Do they really hold ram or is it just cached...

Would be curious.

Last edited by rufessor; 10-31-2014 at 08:33 PM.
rufessor is offline   Reply With Quote
Old 11-01-2014, 04:30 AM   #136
GenoMax
Senior Member
 
Location: East Coast USA

Join Date: Feb 2008
Posts: 7,091
Default

Quote:
Originally Posted by rufessor View Post
I may be answering in part my question- or at least clarifying my question.
I am no longer certain that the sleeping process list actually really effectively did anything to the cache- its almost always used to capacity by linux so I guess my question is-

what the heck are those 40 + sleeping processes doing- and are they effectively actually consuming any resource whatsoever. Do they really hold ram or is it just cached...

Would be curious.
Most modern linux distros manage memory internally so one can't depend on output of htop/top alone. With a TB of RAM you should have no worries about memory consumption

See: http://www.linuxatemyram.com/
GenoMax is offline   Reply With Quote
Old 11-26-2014, 04:30 AM   #137
travelk
Member
 
Location: France

Join Date: Jul 2013
Posts: 20
Default

Hey everyone,

I've used trimmomatic to clean up my reads but when I use the cleaned files in tophat, I get an error. When I examined a bit closer I discovered that trimmomatic converted this:

@D3VDZHS1:119:H036PADXX:1:1202:12533:34018 2:N:0:GGACTCCTTAGATCGC
ATAGACAAATGCCTGCAACAACGCAGGGATCTCTTTCCCGGTAAACCAACCGTCGTCATTGAAGATATGCATGCTGGCTCGGGTATCCCATTGCTGATAC
+
@@CADDFFBBFHHJIGIJJIIJIBDDGE@ABGEHGGGIJIGF:CFFHGIJG<?8ADBDB@AC;.;>A>>@>:@ACC@@?C<BB(0>(:@(4::@(+4>A>
@D3VDZHS1:119:H036PADXX:1:1202:12611:34155 2:N:0:GGACTCCTTAGATCGC
GGTATCAACGCAGAGTACTTTTTTTTTTTCTTTTTTTTTTTTTTTTTTAAAGGAAAACCAGACAAATCATGAAGCCACATACGCTAGAGAAGCTCAATAC
+
B@@DFFDFHHGHHGIEHHIJIIJJJJJJI)BFGG):BCDDDDDDDDB#####################################################
@D3VDZHS1:119:H036PADXX:1:1202:12731:34205 2:N:0:GGACTCCTTAGATCGC
TAATAAATCCGCTACCGACGCTGACTAACATTTCGCGATCGTTCATCGCATCACCAAAGGCCGTGCAATCGCGCAACGATAAACCTAAATGTTGGGTCAG
+
@@CFFFFFHHHHHIJJIIJIIIJJJGIIJJJJJIIJJBAHG@GHEHFGF=BCEEEC?AC?AAB8888@CC??>BBDD>BBBBCDDAACDCDDC@8<?CBC


TO:

@D3VDZHS1:119:H036PADXX:1:1202:12533:34018 2:N:0:GGACTCCTTAGATCGC
ATAGACAAATGCCTGCAACAACGCAGGGATCTCTTTCCCGGTAAACCAACCGTCGTCATTGAAGATATGCATGCTGGCTCGGGTAT+
@@CADDFFBBFHHJIGIJJIIJIBDDGE@ABGEHGGGIJIGF:CFFHGIJG<?8ADBDB@AC;.;>A>>@>:@ACC@@?C<BB(0>
@D3VDZHS1:119:H036PADXX:1:1202:12731:34205 2:N:0:GGACTCCTTAGATCGC
TAATAAATCCGCTACCGACGCTGACTAACATTTCGCGATCGTTCATCGCATCACCAAAGGCCGTGCAATCGCGCAACGATAAACCTAAATGTTGGGTCAG
+
@@CFFFFFHHHHHIJJIIJIIIJJJGIIJJJJJIIJJBAHG@GHEHFGF=BCEEEC?AC?AAB8888@CC??>BBDD>BBBBCDDAACDCDDC@8<?CBC

Obviously trimmomatic didn't put + on the next line and now tophat can't read the line properly. This has happened in multiple files. Does anyone know if a) this is normal for trimmomatic and I need to fix this manually or if b) I did something wrong to cause it?

My input code:

Code:
java -jar /path/to/Trimmomatic-0.32/trimmomatic-0.32.jar PE -threads 8 -phred33 -trimlog Sample1trimlog sample1_R1.fastq sample1_R2.fastq sample1_R1_TP.fastq sample1_R1_TU.fastq sample1_R2_TP.fastq sample1_R2_TU.fastq ILLUMINACLIP:/path/to/Trimmomatic-0.32/adapters/adapters.fa:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36
Thanks for your help!
travelk is offline   Reply With Quote
Old 11-26-2014, 06:18 AM   #138
westerman
Rick Westerman
 
Location: Purdue University, Indiana, USA

Join Date: Jun 2008
Posts: 1,104
Default

Quote:
Originally Posted by travelk View Post
Obviously trimmomatic didn't put + on the next line and now tophat can't read the line properly. This has happened in multiple files. Does anyone know if a) this is normal for trimmomatic and I need to fix this manually or if b) I did something wrong to cause it?
a) No. Not normal.

b) Probably. But your command line looks ok and nothing obvious is popping up.
westerman is offline   Reply With Quote
Old 11-26-2014, 06:56 AM   #139
tonybolger
Senior Member
 
Location: berlin

Join Date: Feb 2010
Posts: 156
Default

Quote:
Originally Posted by travelk View Post
Obviously trimmomatic didn't put + on the next line and now tophat can't read the line properly. This has happened in multiple files. Does anyone know if a) this is normal for trimmomatic and I need to fix this manually or if b) I did something wrong to cause it?
It is certainly not normal - it's one of the strangest trimmomatic issue i have heard of. None the less, it should be possible to track down. Some questions:

1) Does this happen consistently on the same lines of the same files if they are run more than once?
1.1) If so, can you isolate and send me a short example where it happens?

2) What OS are you using?

Thanks,

Tony.
tonybolger is offline   Reply With Quote
Old 11-27-2014, 04:55 AM   #140
travelk
Member
 
Location: France

Join Date: Jul 2013
Posts: 20
Default

Ok, I re-ran the files using the exact same script on the exact same files as suggested to check if it happened consistently on the same line... but now there is no problem with the new output files and tophat runs them just fine. So, I'm not sure what I did the first time around to have the files corrupt like that.

Thank you nevertheless for taking the time to help me!
travelk is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 01:34 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO