Bins get assigned a taxonomy when they have no markers about checkm

[donovan-h-parks]

Hey Connor,

The set of marker genes used to place a genome into the reference genome tree is not the same as the set used to calculate completeness and contamination. Having said that, these results are still very surprising. Can you please run the following and see how many phylogenetically informative marker genes these bins have (out of 43):

checkm tree_qa [output_dir]

Bins with less than 10 marker genes by default should be assigned to root (see checkm lineage_wf or checkm lineage_set). However, perhaps there is a bug here as it is hard to imagine all the bins you have listed actually have this many phylogenetic marker genes.

Cheers,
Donovan

[ctSkennerton]

Hi Donovan,

These are the results from tree_qa for the bins listed above

final.contigs.fa.metabat-bins-.53   12  0   k__Bacteria;p__Proteobacteria;c__Deltaproteobacteria;o__Desulfobacterales;f__Desulfobacteraceae
final.contigs.fa.metabat-bins-.54   28  4   k__Bacteria;p__Chloroflexi
final.contigs.fa.metabat-bins-.59   35  7   k__Bacteria;p__Proteobacteria;c__Deltaproteobacteria;o__Desulfuromonadales;f__Geobacteraceae
final.contigs.fa.metabat-bins-.6    27  0   k__Archaea;p__Euryarchaeota;c__Methanomicrobia;o__Methanosarcinales
final.contigs.fa.metabat-bins-.60   9   0   k__Bacteria;p__Proteobacteria;c__Gammaproteobacteria

[donovan-h-parks]

Hey Connor,

Bins are placed using the phylogenetically-informative set of 43 marker genes. Since all your bins have 1 or more of these marker genes they are all placed in the reference genome tree. Bin 60 only has 9 of these genes (less than the default of 10 required) so is evaluated with a domain-level set of marker genes. The others are all evaluated using lineage-specific marker genes. What is surprising here is that these genomes all seem to have phylogenetically-informative marker genes, but no lineage-specific marker genes. Is this just a small set among many that appear correct? I'm guess this results are accurate even if they are surprising.

As an additional check, you could run domain-specific sets over these bins just to verify that they indeed appear to be missing these expected genes.

[ctSkennerton]

Hi Donovan,

I think the lineage_wf command has some non-deterministic behaviour! I took the bins listed above and ran just the 5 of them in a separate checkm run and got very different results (see below). I think these results are correct, or at least more correct than when I ran them with the other bins as the completeness matches up better with the count from the universal set of markers

final.contigs.fa.metabat_bins_59    c__Deltaproteobacteria  (UID3216)   83  248 156 58  146 39  5   0   0   70.09   17.98
final.contigs.fa.metabat_bins_54    k__Bacteria (UID1452)   924 163 110 55  100 8   0   0   0   62.92   3
final.contigs.fa.metabat_bins_60    k__Bacteria (UID203)    5449    104 58  63  40  1   0   0   0   62.07   0.86
final.contigs.fa.metabat_bins_6 p__Euryarchaeota    (UID49) 95  229 154 100 125 4   0   0   0   48.63   2.11
final.contigs.fa.metabat_bins_53    c__Deltaproteobacteria  (UID3216)   83  248 156 215 30  3   0   0   0   10.11   0.85

[ctSkennerton]

I've just done some more sleuthing and found that running the bins through lineage_wf with a single thread gives the correct results (before I was running the full dataset through with 32 threads). It could be that there is a thread lock missing somewhere such that data is getting overwritten.

[donovan-h-parks]

The lineage_wf command is not deterministic as pplacer is not deterministic. I think it is telling that the selected node (as given by the UIDs) is identical in the two examples you have sent me (first message and last message). Note that the UIDs will be different between the qa and tree_qa commands. The first indicates which node was used to calculate lineage-specific marker sets, while the second indicates the closes node to where the genome was inserted by pplacer. As such, the latter will always be more specific as is the case here.

I will play around with multi-threading today to see if there is indeed some sort of race condition.

[donovan-h-parks]

I can't reproduce the problem on my end. I get identical results over a set of 30 bins between runs regardless of if I use multiple threads or a single threads. I've run this six times without any deviation. Are your results jumping from reasonable estimates to estimates of 0% completeness and contamination (as per your first post)? Can you put your bins somewhere for me so I can play with them and send me the exact command you are running? Ta!

[donovan-h-parks]

Fixed after update to latest version.