[maria.gr]

Hi guys !
I m new to trim_galore and I have a small issue introducing cutadapt in the command line of trim_galore :
Could you tell me how I should modify this line so that I introduce the cutadapt directory?

>>
./trim_galore --paired --retain_unpaired --quality 15 --fastqc_args $path_to_cutadapt='build/cutadapt' --fastqc my1.fastq.gz my2.fastq.gz

[mvijayen]

That worked just fine! Thanks, Felix!

[fkrueger]

That path seems to be lacking /cutadapt at the end. Could you try that?

[mvijayen]

Hi Felix,

I failed to mention that I actually did try that as well:

# change these paths if needed
my $path_to_cutadapt = '/Users/mvijayen/cutadapt-1.3/bin';

I am still getting the same error.

[fkrueger]

If Cutadapt is not in the PATH you need to give Trim Galore the absolute path to where it can be found. Since you are saying that ./cutadapt works fine you seem to have installed it in that current directory. If you type 'cwd' and copy that path into the first part of Trim Galore that says $path_to_cutadapt = '' it should all work fine (just edit it with any editor).

Cheers,
Felix

[mvijayen]

Hi all,

I am running into an error with trim_galore. Would anyone have any idea on what I may be doing wrong?
Command line: ./trim_galore --paired /Users/mvijayen/fastq/sample_1.fastq /Users/mvijayen/fastq/sample_2.fastq

No quality encoding type selected. Assuming that the data provided uses Sanger encoded Phred scores (default)

Writing report to 'sample_1.fastq_trimming_report.txt'

SUMMARISING RUN PARAMETERS
==========================
Input filename: /Users/mvijayen/fastq/sample_1.fastq
Quality Phred score cutoff: 20
Quality encoding type selected: ASCII+33
Adapter sequence: 'AGATCGGAAGAGC'
Maximum trimming error rate: 0.1 (default)
Minimum required adapter overlap (stringency): 1 bp
Minimum required sequence length for both reads before a sequence pair gets removed: 20 bp

Writing final adapter and quality trimmed output to sample_1_trimmed.fq


>>> Now performing quality (cutoff 20) and adapter trimming in a single pass for the adapter sequence: 'AGATCGGAAGAGC' from file /Users/mvijayen/fastq/sample_1.fastq <<<
open3: exec of cutadapt -f fastq -e 0.1 -q 20 -O 1 -a AGATCGGAAGAGC /Users/mvijayen/fastq/sample_1.fastq failed at ./trim_galore line 471

RUN STATISTICS FOR INPUT FILE: /Users/mvijayen/fastq/sample_1.fastq
=============================================
0 sequences processed in total
Illegal division by zero at ./trim_galore line 565.


I am using trim_galore version 0.3.3 and cutadapt seems to be working just fine when I check with ./cutadapt -h. Thanks!

[optimuscoprime]

If you like Trim Galore!, you might also like:

https://github.com/optimuscoprime/autoadapt

It uses FastQC to detect adaptors and primers, and then cuts them with cutadapt (well, in parallel using several cutadapts)

[fkrueger]

A quick notice that I have just put out a new version of Trim Galore (v0.3.3) that fixes a bug I had introduced accidentally last week where single-end trimming would add an empty line into the trimmed sequence output.

[fkrueger]

Thanks for reporting this. These warnings occurred if the sequence had been adapter- or quality-trimmed below the clipping threshold. I have now added an additional check to prevent this from happening.

A new version of Trim Galore is now available from its project page (https://www.bioinformatics.babraham....s/trim_galore/), which also fixes one additional issue:

- Specifying --clip_R1 or --clip_R2 will no longer attempt to clip sequences hat have been adapter- or quality-trimmed below the clipping threshold
- Specifying an output directory with --rrbs mode should now correctly create temporary files

[ringprince]

problems with --clip_R1

Hi all,

I am having issues when using the --clip_R1 option.

trim_galore --clip_R1 3 test2.fastq.gz

Gives me a lot of

substr outside of string at ../../programs/trim_galore/trim_galore line 503, <TRIM> line 43696.
substr outside of string at ../../programs/trim_galore/trim_galore line 504, <TRIM> line 43696.
Use of uninitialized value in numeric lt (<) at ../../programs/trim_galore/trim_galore line 507, <TRIM> line 43696.

Without the clipping it works fine.

I am on Linux (amd64) and I use version 0.3.1 (Last update: 18 07 2013)

Attached is a sample file that produces one of these errors for me.

Regards

[gerald2545]

Hi Felix,
no worry about the late reply, I knew that you were on holiday.

Thank you for the information. Maybe for paired-ends run, the following sentence could be omitted in the report :
"Sequences removed because they became shorter than the length cutoff of 20 bp: 0 (0.0%)"
and just write down the information for the pairs :
"Number of sequence pairs removed because at least one read was shorter than the length cutoff (20 bp): 2697629 (10.10%)"
?

have nice holidays

Gérald

PS : sorry for my late reply too, I didn't receive the notification email as my adress was wrong

[fkrueger]

Hi Gerald,

Trim galore does not remove any reads 1 or read 2 individually if they became too short during trimming, but only does so after both reads have been trimmed (a validation step). This is done to ensure that the files do not get out of sync because of trimming.

Considering the output of Cutadapt I would guess that the 2 values are quite similar in your case, but as you said this is the output straight from cutadapt. apologies for my slow response but I am currently on holiday.

Best, Felix

[gerald2545]

It seems that 0 reads were removed for R1 due to length, 0 reads were removed for R2 due to length but 2697629 pairs were removed because at least one read was shorter than the length cutoff
Is there someting that I don't well understand?
We have just installed the latest version, but did'nt try it yet (but you don't mention this in your release notes, so I don't think the behaviour will be different)

just tested with 0.3.1 version, we notice the same behaviour

Best regards

Gérald

[gerald2545]

Hi all,
we noticed something strange in TrimGalore! (0.2.8) result file, for a WGBS 2x101 paired-ends run :

RUN STATISTICS FOR INPUT FILE: /work/ng6/jflow/methylSeq/wf000619/ConcatenateFilesGroups_default/A3_CACGAT_L002_R1.fastq.gz
=============================================
26711665 sequences processed in total
Sequences removed because they became shorter than the length cutoff of 20 bp: 0 (0.0%)

RUN STATISTICS FOR INPUT FILE: /work/ng6/jflow/methylSeq/wf000619/ConcatenateFilesGroups_default/A3_CACGAT_L002_R2.fastq.gz
=============================================
26711665 sequences processed in total
Sequences removed because they became shorter than the length cutoff of 20 bp: 0 (0.0%)

Total number of sequences analysed for the sequence pair length validation: 26711665

Number of sequence pairs removed because at least one read was shorter than the length cutoff (20 bp): 2697629 (10.10%)

It seems that 0 reads were removed for R1 due to length, 0 reads were removed for R2 due to length but 2697629 pairs were removed because at least one read was shorter than the length cutoff

Is there someting that I don't well understand?

We have just installed the latest version, but did'nt try it yet (but you don't mention this in your release notes, so I don't think the behaviour will be different)

Thank you for your answer

Another thing, but it may be a cutadapt output problem. In the report file, cutadapt section :

cutadapt version 1.2.1
Command line parameters: -f fastq -e 0.1 -q 20 -O 1 -a AGATCGGAAGAGC /work/ng6/jflow/methylSeq/wf000619/ConcatenateFilesGroups_default/A3_CACGAT_L002_R1.fastq.gz
Maximum error rate: 10.00%
No. of adapters: 1
Processed reads: 26711665
Processed bases: 2671166500 bp (2671.2 Mbp)
Trimmed reads: 10940767 (41.0%)
Quality-trimmed: 168748516 bp (177.0 Mbp) (6.32% of total)
Trimmed bases: 177017106 bp (177.0 Mbp) (6.63% of total)

Quality-trimmed and Trimmed bases have different number of bp reported, but the number in Mb is the same. It seems that the number of bases in Mbp used in Quality-trimmed comes from the Trimmed bases result.


Gerald

[fkrueger]

Do you mean mate-pair or paired-end libraries? At least paired-end libraries typically share the same starting sequence of the adapters on both ends of each fragment, so you wouldn't have to supply different sequences or reverse complements but simply run Trim Galore in default mode. If you really wanted to run several consecutive steps it can't be guaranteed that you only trim off one adapter per sequence.