UMI-based error correction

[bshim181]

This is a UMI distribution I see for one of my samples. I was wondering what parameters are suggested to modify to relax level of UMI filtering conducted here (possibly lower the UMI filtering threshold by 3 reads per UMI rather than 10 shown on this graph)

[mizraelson]

Hi, I would first check the refineTagsAndSort report to see the percentage of reads that are being filtered out. To manually set the UMI filter, you can use the following parameters with the mixcr analyze command:

-M.refineTagsAndSort.parameters.postFilter=null
-M.assemble.consensusAssemblerParameters.assembler.minRecordsPerConsensus=3

[bshim181]

If I want to lower the percentage of UMIs getting filtered out, while not setting the hard threshold, is there a way to do so?
I am aware that these thresholds are empirically chosen for each dataset, so is there a parameter to influence the threshold decision?

[mizraelson]

Currently, there is no direct way to loosen the algorithm. If the reports indicate that the number of filtered-out reads is low, I recommend using the default settings.

[bshim181]

Hello, thank you for your suggestion. I have tried out minRecordsPerConsensus=3.
One thing I noticed from the assembler report is that, there is high "Number of assembling feature sequences in groups with zero pre-clonotypes" which I believe leads to high percentage of discarded core alignments. These numbers stay consistent whether I set -M.assemble.consensusAssemblerParameters.assembler.minRecordsPerConsensus=3 or not. I was wondering what exactly this number refers to and what might be the cause for this?

[mizraelson]

Number of assembling feature sequences in groups with zero pre-clonotypes refers to the number of alignments in UMI groups for which it was impossible to assemble a consensus. This could occur, for example, if there are many different clones within the same UMI group—such as 10 reads each with a different CDR3 sequence in the same group.