# Problem with mothur v 1.47 count\_table is not maintaining groups

**URL:** <https://forum.mothur.org/t/problem-with-mothur-v-1-47-count-table-is-not-maintaining-groups/21337>\
**Category:** mothur bugs\
**Created:** [March 16, 2022, 10:48pm UTC](https://forum.mothur.org/t/problem-with-mothur-v-1-47-count-table-is-not-maintaining-groups/21337 "2022-03-16T22:48:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jmacnico](https://avatars.discourse-cdn.com/v4/letter/j/b4bc9f/32.png) [@jmacnico](https://forum.mothur.org/u/jmacnico)\
**Post date:** [March 16, 2022, 10:48pm UTC](https://forum.mothur.org/t/problem-with-mothur-v-1-47-count-table-is-not-maintaining-groups/21337/1 "2022-03-16T22:48:42Z")

</div>

I ran into this problem when I went to do my shared file for a phylotype based analysis.

[WARNING]: Your count file does not have group info, all reads will be assigned to mothurGroup.

I didn’t think anything of it at the time because I knew there were some new synthesis of the commands in this version. BUT when I got to my count groups prior to subsampling there was only 1 group… uhoh

I noticed that in my pre.cluster command I got this note:  
When using running without group information mothur can only use 1 processor, continuing.

I went back through my count\_tables from all my commands and it looks like for some reason after I run unique.seqs the first time my count\_table file no longer includes my samples as groups. So the file looks something like this:

| Representative\_Sequence | total |
| --- | --- |
| M05184\_45\_000000000-KB33R\_1\_2112\_21024\_17034 | 276976 |
| M05184\_45\_000000000-KB33R\_1\_1103\_3487\_14047 | 702 |
| M05184\_45\_000000000-KB33R\_1\_1106\_15957\_20033 | 21465 |
| M05184\_45\_000000000-KB33R\_1\_1102\_14353\_26226 | 954 |
| M05184\_45\_000000000-KB33R\_1\_2113\_16846\_8860 | 50451 |
| M05184\_45\_000000000-KB33R\_1\_1109\_26590\_14472 | 25 |
| M05184\_45\_000000000-KB33R\_1\_2107\_22239\_13176 | 66 |

As opposed to what it usually does which is more like:

#Compressed Format: groupIndex,abundance. For example 1,6 would mean the read has an abundance of 6 for group HC1.  
#1,HC1 2,HC100 3,HC101 4,HC102 5,HC103 6,HC104 7,HC105 8,HC106 9,HC107 10,HC108 11,HC109 12,HC11 13,HC110 14,HC111 15,HC112 16,HC113 17,HC114 18,HC115 19,HC116 20,HC117 21,HC118 22,HC119 23,HC12 24,HC120

so all that jazz BEFORE the representative sequence total info.

I also noticed that in the SOP after the first screen.seqs command the files are named:  
fasta=stability.trim.contigs.fasta  
contigsreport=stability.contigs\_report  
count=stability.contigs.count\_table

Whereas mine are:  
stability.trim.contigs.good.fasta  
stability.trim.contigs.bad.accnos  
stability.contigs.good.count\_table

I don’t think there is any difference in these files other than they have the “good”, but then throughout the workflow the file names don’t really align.

Not really sure where I might have gone wrong or what I’m missing 😕 😕

---

<div class="post-metadata">

**Author:** ![westcott](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/westcott/32/18_2.png) [@westcott](https://forum.mothur.org/u/westcott)\
**Post date:** [March 17, 2022, 3:51pm UTC](https://forum.mothur.org/t/problem-with-mothur-v-1-47-count-table-is-not-maintaining-groups/21337/2 "2022-03-17T15:51:27Z")

</div>

The issue is caused by not including the existing count file in commands. It starts with this command:

mothur \> unique.seqs(fasta=current) - generate new count file with no groups

try this instead:

mothur \> unique.seqs(fasta=current, **count=current** ) - update existing count file to combine identical reads.

---

<div class="post-metadata">

**Author:** ![system](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.mothur.org/system/32/2_2.png) [@system](https://forum.mothur.org/u/system)\
**Post date:** [March 27, 2022, 3:51pm UTC](https://forum.mothur.org/t/problem-with-mothur-v-1-47-count-table-is-not-maintaining-groups/21337/3 "2022-03-27T15:51:53Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
