Chimera.uchime broken in 1.32.0

mothur bugs
1

Something isnt working in chimera.uchime or related code in version 1.32.0.

I get a ton of errors like this:

[ERROR]: Your count table contains a sequence named RUN1_1_1101_18820_16351 with a total=0. Please correct.

But the corresponding entries in my count_file definitely dont total to zero:

RUN1_1_1101_18820_16351 62 51 5 1 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

The same batch file runs without problem on 1.31.2, and I’ve had the same error in two different data sets. I am loosely following the MiSeq SOP, with my own data sets. Let me know if you need me to provide data to reproduce this issue.

2

In version 1.32.0, we added an error flag in the count table to catch tables that where not made by mothur and had zero totals. Zero totals caused issues in some of mothur’s commands because mothur expects a representative sequence to at least represent itself. When chimera.uchime runs with a count table and dereplicate=t, it can create a temporary table with 0 counts, but then adjusts the table and prints it. Mothur is complaining about the temporary table. Thanks for reporting the issue. We will release a patch for this later this week, but in the meantime as a work around you could run the SOP with names and groups files, and then create the count table after the chimera.uchime command.

3

Version 1.32.1 is up on the wiki and it includes the fix for this bug.

4

I had the same problem in 1.32.0 and I have updated to 1.32.1 now, however I am still running into errors like the following:

[ERROR]: M00763_18_000000000-A6DEW_1_1101_23407_24535/ab=21/ is not in your count table. Please correct.

It seems that the temporary table has “/ab=X/” added to the identifiers. Any idea why that happens?

5

I am not seeing that error on our end. Could you post the chimera.uchime command you ran and the OS you are running mothur on?

6

Sure, the command I am trying to run is:

chimera.uchime(fasta=stability.trim.contigs.good.unique.good.filter.unique.precluster.fasta, count=stability.trim.contigs.good.unique.good.filter.unique.precluster.count_table, dereplicate=T, reference=silva.gold.ng.fasta, processors=8)

on a Linux system. I am following the guide here: http://www.mothur.org/wiki/MiSeq_SOP, so the input files to chimera.uchime are produced by the pre.cluster command. Let me know if I can provide any more info.

7

Mothur should include an error message in this case. The command is not designed to be run this way. You can run it with the silva sequences as the reference, or use the abundance information in the count table to check the less abundant sequences against the more abundant, but not both. If you are following the MISeq SOP just leave off the silva reference and run the command.

8

Thanks, I will try that. So if I wanted to run chimera.uchime with a reference I would just leave out the count parameter?

9

Yes, that is correct.

10

I am seeing the same error following the MiSeq SOP:

[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_9814_8689 with a total=0. Please correct.
[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_2857_10432 with a total=0. Please correct.
[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_13028_17777 with a total=0. Please correct.
[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_12343_20096 with a total=0. Please correct.
[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_6961_21614 with a total=0. Please correct.
[ERROR]: Your count table contains a sequence named M01168_77_000000000-A59UE_1_2114_16376_26587 with a total=0. Please correct.
...

The command used was:

chimera.uchime(fasta=jt.trim.contigs.good.unique.good.filter.unique.precluster.fasta, count=jt.trim.contigs.good.unique.good.filter.unique.precluster.count_table, dereplicate=t)

Mothur v.1.32.0

11

I believe the bug was fixed in v.1.32.1 so you would have to update your program to avoid running into that problem.

12

This is fixed in the current version, 1.32.1, Redirecting….