Mate mismatch on multi-file mode

[billytaj]

Hi, I ran into an issue using Adapterremoval on a dataset with a very weird situation:

• AdapterRemoval was run on multi-file mode
  I was lead to believe that the paired-end mode would automatically assume that --file1 and --file2 were forward and reverse end reads like it did in all other cases, but it seems to be choking.
  What would cause something like this?

the data in question is a part of the NCBI SRA:
project: PRJNA389280
SRR5947944_1.fastq
SRR5947944_2.fastq

The read IDs are the same for each file, so the only way to check for forward-or-reverse was the filename, which has been fine up to now for all other data, except with this set.

[MikkelSchubert]

Hi Billy, What do you mean when you write that AdapterRemoval "seems to be choking"? What error message(s) did you receive, if any? Best regards, Mikkel

…

On Tue, Oct 16, 2018 at 5:43 AM Billy Taj ***@***.***> wrote: Hi, I ran into an issue using Adapterremoval on a dataset with a very weird situation: - AdapterRemoval was run on multi-file mode I was lead to believe that the paired-end mode would automatically assume that --file1 and --file2 were forward and reverse end reads like it did in all other cases, but it seems to be choking. What would cause something like this? the data in question is a part of the NCBI SRA: project: PRJNA389280 SRR5947944_1.fastq SRR5947944_2.fastq The read IDs are the same for each file, so the only way to check for forward-or-reverse was the filename, which has been fine up to now for all other data, except with this set. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACTMa026ZjW9emGcSJpwbZzUVk1uGe9eks5ulVXXgaJpZM4Xdhc7> .

[billytaj]

Trimming paired end reads ...
Error in thread:
Pair contains reads with mismatching names:

• 'SRR5947945.100791'
• 'SRR5947945.101693'

Note that AdapterRemoval by determines the mate numbers as
the digit found at the end of the read name, if this is
preceeded by the character '/'; if these data makes use of a
different character to separate the mate number from the
read name, then you will need to set the --mate-separator
command-line option to the appropriate character.
Error in thread:
Pair contains reads with mismatching names:

• 'SRR5947945.101400'
• 'SRR5947945.100533'

Note that AdapterRemoval by determines the mate numbers as
the digit found at the end of the read name, if this is
preceeded by the character '/'; if these data makes use of a
different character to separate the mate number from the
read name, then you will need to set the --mate-separator
command-line option to the appropriate character.

I got this error message when using adapter-removal in multi input mode.

[MikkelSchubert]

Thanks! When you say that you used adapterremoval in "multi input mode", do you mean that you are specifying multiple files for each of --input1 and --input2 or simply that you are using both of those options? If you have multiple files for each option, are you specifying those manually or using wildcards? If you are using wildcards, then the problem may be that the files for --input1 and --input2 are listed in different orders, which would results in incorrect pairings of reads. You can make sure that the order is similar by using something like --input1 $(ls /path/to/files/*.fastq.gz | sort)

…

On Tue, Oct 16, 2018 at 7:32 PM Billy Taj ***@***.***> wrote: Trimming paired end reads ... Error in thread: Pair contains reads with mismatching names: - 'SRR5947945.100791' - 'SRR5947945.101693' Note that AdapterRemoval by determines the mate numbers as the digit found at the end of the read name, if this is preceeded by the character '/'; if these data makes use of a different character to separate the mate number from the read name, then you will need to set the --mate-separator command-line option to the appropriate character. Error in thread: Pair contains reads with mismatching names: - 'SRR5947945.101400' - 'SRR5947945.100533' Note that AdapterRemoval by determines the mate numbers as the digit found at the end of the read name, if this is preceeded by the character '/'; if these data makes use of a different character to separate the mate number from the read name, then you will need to set the --mate-separator command-line option to the appropriate character. I got this error message when using adapter-removal in multi input mode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACTMay2qHN3ODTfRdYthon7bGIRZKauPks5ulhhJgaJpZM4Xdhc7> .

[billytaj]

I am using --file1 and --file2, where each entry is an absolute path to the files (forward, and reverse)

[MikkelSchubert]

Thank you. I've been trying to reproduce the problem with the same data, but unfortunately I have not been able to do so. Can you copy paste the exact commands you used to run AdapterRemoval and as well as the commands you used to download the FASTQ reads? While I was unable to reproduce the error you've gotten, I did notice that the 'fasterq-dump' tool appears to produce files with different numbers of reads. But that should have resulted in a different error, so I assume that you used the 'fastq-dump' tool to download the data?

…

On Tue, Oct 16, 2018 at 8:52 PM Billy Taj ***@***.***> wrote: Reopened #28 <#28>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACTMazduw7LUyCxn9ZnSM3l8bXQKGpnpks5ulirRgaJpZM4Xdhc7> .

[billytaj]

I produced the files using fasterq-dump. I also only take an inner-join of the 2 files, so the files would have the exact same read IDs
Please don't use the exact result as a guidepost. I received 2 messages of "error in thread. pair mismatches"

I solved the problem by appending the reads with a /1 and /2, and sending it off to AdapterRemoval, though I feel this is an unnecessary step.