Should you use pooled chimera filtering on a merged dataset?

[hjarnek]

Hello,

I have a question about pooling and chimera filtering. I understand that the rule of thumb is to use pooled chimera filtering only on datasets that were denoised in pooled mode (i.e. removeBimeraDenovo(method = "pooled") on dada(pool = TRUE)), and non-pooled chimera filtering on datasets that were not pooled during denoising (i.e. removeBimeraDenovo(method = "consensus") on dada(pool = "pseudo") or dada(pool = FALSE)). But what do you do when your dataset is made up of several individually denoised datasets that were merged with mergeSequenceTables(), assuming they were all denoised in pooled mode? Chimera filtering should perform better on a larger dataset, but is it still recommended in this situation, and in which mode?

And a follow-up question: assume some datasets making up the merged dataset were denoised in pooled mode and some in pseudo-pooled mode?

Another problem of merging datasets is that they might have very different sequencing depth, which can mess with chimera detection. The obvious example is pooling a NovaSeq dataset with a MiSeq dataset and then doing chimera filtering, which I guess isn't advisable. But even datasets sequenced on the same type of flow cell can have very varying sequencing depth depending on how many samples were multiplexed on the flow cell, so what is the recommended way of dealing with that? When should you do chimera filtering on the merged dataset and when should you not?

[benjjneb]

But what do you do when your dataset is made up of several individually denoised datasets that were merged with mergeSequenceTables(), assuming they were all denoised in pooled mode?

Good question that I don't have a good answer to. I think I would use the default chimera removal mode in this case, but there isn't a perfect match between chimera removal mode and denoising mode here.

When should you do chimera filtering on the merged dataset and when should you not?

I would always recommend doing chimera filtering on the total datasets (post mergeSequenceTables). Even more important than getting chimera identification right is doing it consistently across the "batches" that mergeSequenceTables brings together. If you do it individually you risk identifying an ASV as a chimera in one batch and not in another, yielding a huge batch effect for that ASV.

Also to add: pseudo-pooled data should be chimera checked with the default method. Only fully pooled data at the denoising step should use the pooled method in removeBimeraDenovo.

[hjarnek]

Thanks for your response, @benjjneb.

I understand your point about the batch effect, which could indeed be troublesome. But do you mean that one should filter chimeras on the merged dataset even if it consists of both MiSeq and NovaSeq data, averaging an order of magnitude different sequencing depth? How many false positive chimeras on the MiSeq samples should I expect?

This is a situation that we constantly find ourselves in, and working with "big data", or data from different studies, mergeSequenceTables is being used all the time.

[benjjneb]

But do you mean that one should filter chimeras on the merged dataset even if it consists of both MiSeq and NovaSeq data, averaging an order of magnitude different sequencing depth?

Yes.

How many false positive chimeras on the MiSeq samples should I expect?

I can't give you a good answer on that.

There will be mistakes made in chimera classification when combining datasets generated by different technologies. But the mistakes made by performing chimera classification on each batch individually are worse -- they can create strong signals associated with the batch that don't really exist because in one batch an ASV was classified as a chimera and in another batch it wasn't.