different results from Trim galore command line and galaxy version.

input is a paired read
@A00917:1431:H7WVLDSXC:4:1112:1181:36385 1:N:0:CACTATCGTC+ATGCTGCGTT

@A00917:1431:H7WVLDSXC:4:1112:1181:36385 2:N:0:CACTATCGTC+ATGCTGCGTT

After trimming with command line:
@A00917:1431:H7WVLDSXC:4:1112:1181:36385 1:N:0:CACTATCGTC+ATGCTGCGTT

After trimming with galaxy:
@A00917:1431:H7WVLDSXC:4:1112:1181:36385 1:N:0:CACTATCGTC+ATGCTGCGTT

Results for Read2 are the same for both galaxy and command line. So I am not showing it here.

command line (trim galore 0.6.10):
trim_galore --cores 1 --phred33 --quality 20 --stringency 1 -e 0.1 --length 20 --output_dir /mnt/d/desktop/result6 --paired different.lines.in.original_read1.fq different.lines.in.original_read2.fq

I noticed the “AGATCTGAAGA” in my read is similar to illumina adapter.
But I cannot figure our what is causing the difference in results from command line and galaxy server. In addition, the galaxy result is correct, I wonder how I can make the command line work as expected.


@lidong I cannot really comment on the output differences without knowing what exactly you’ve been doing on the Galaxy side, but:

you can find the command line that Galaxy executed for your tool run by going to Dataset Details (click the “i” icon on the expanded dataset) and scrolling down, in the central panel, to Job Information.

Additionally, please note that you’re running trim galore 0.6.10 on the command line, but the Galaxy tool wrapper is currently using 0.6.7, which may or may not cause some differences, too.

You can also find the command line tool’s very detailed output about its operations in that same section under Tool Standard Error.

here is the run info from galaxy:
ln -s ‘/jetstream2/scratch/main/jobs/56506574/inputs/dataset_b28f78e3-7b0e-40c9-81e6-03bdd57c5192.dat’ input_1.fastq.gz && ln -s ‘/jetstream2/scratch/main/jobs/56506574/inputs/dataset_fe72a65e-ae19-479e-8968-e166f70149d3.dat’ input_2.fastq.gz && trim_galore --cores ${GALAXY_SLOTS:-4} --phred33 --quality 20 --stringency 1 -e 0.1 --length 20 --output_dir ./ --no_report_file --paired input_1.fastq.gz input_2.fastq.gz && if [ -f input_1_trimmed.fq.gz ] ; then mv input_1_trimmed.fq.gz input_1_trimmed.fq ; fi && if [ -f input_1_val_1.fq.gz ] ; then mv input_1_val_1.fq.gz input_1_val_1.fq ; fi && if [ -f input_2_val_2.fq.gz ] ; then mv input_2_val_2.fq.gz input_2_val_2.fq ; fi && if [ -f input_1_unpaired_1.fq.gz ] ; then mv input_1_unpaired_1.fq.gz input_1_unpaired_1.fq ; fi && if [ -f input_2_unpaired_2.fq.gz ] ; then mv input_2_unpaired_2.fq.gz input_2_unpaired_2.fq ; fi && if [ -f input_1.clock_UMI.R1.fq.gz ] ; then mv input_1.clock_UMI.R1.fq.gz input_1.clock_UMI.R1.fq ; fi && if [ -f input_2.clock_UMI.R2.fq.gz ] ; then mv input_2.clock_UMI.R2.fq.gz input_2.clock_UMI.R2.fq ; fi && ls -lah

As far as I can tell, they are the same as the ones used for command line.
I was told the parameter “-e 0.1” is causing the unwanted trimming in my command line result, which I think makes sense. Now I don’t understand why “-e 0.1” is not causing the same problem with galaxy.